Comparing SmartThings to other Ecosystems (Google, Amazon, Apple, etc)

DanielSiegel · August 20, 2019, 9:42pm

I posted this on the webCore forum, but wanted to post it here as well.
I have been a generally happy (sometimes frustrated) SmartThings user for less than a year, and am using webcore with various devices (including 100+ Fibaro light switches). I am curious whether others have had experience with other ecosystems (Google, Amazon, Apple, etc) in addition to SmartThings.

In particular, do they adopt the same general architectural approach as SmartThings of executing “device handlers” in their respective clouds (as well as on a local Hub) – ie, supplementing the firmware on the physical device itself? If a physical device supports the network protocol of a Hub (ie, as a “gateway”), must the manufacturer also write a custom “device handler” to provide compatibility with that ecosystem (eg, would a device that supports WiFi still not work with a Google Hub unless the mfr of the device writes a device handler)?

Do they all provide something akin to webCore for extensibility – ie, to supplement the built-in features of a Hub with a full-featured programming/scripting environment?

And do they all provide “interoperability” across ecosystems via “plugins” (eg, a SmartThings Smart App or an Alexa “skill”)?

Just trying to get a feel for the overall IoT world and whether we are getting closer to (or further from) interoperability of devices across these various “de facto standard” ecosystems.

Appreciate any thoughts from those with experience across these different ecosystems (beyond just SmartThings).

JDRoberts · August 20, 2019, 9:51pm

There’s just a huge amount of variation and every company does it a little differently. So there’s no general answer to be given to your question.

Apple’s HomeKit, for example, runs everything locally except for Siri voice processing, and that is anonymized before it is sent to the cloud. True programmers can do their own development and add additional devices, but your typical customer won’t. It’s pretty much a “set and forget“ system.

Hubitat, A tiny company founded about two years ago by some former smartthings users has a very similar language to smartthings and is compatible with most of the same devices, but intentionally by design runs everything locally except for optional third-party integrations.

Homeseer, A larger, older company which predates smartthings has the same design philosophy as Hubitat: everything local except optional third-party integrations. It allows for individual code and a lot of extensibility, but customers have to have a strong technical background to use it.

Amazon allows customers to create their own interfaces to echo through the echo skills platform. Most of that platform is designed around cloud to cloud integrations, although if you have an echo show second generation or echo plus you can add local control of zigbee devices. But no local skills.

So again, just huge variation.

JDRoberts · August 20, 2019, 10:00pm

As far as this goes, the American capitalist system encourages variation. Not standardization.

There’s a competitive market advantage in not being universally compatible, And that remains true in security systems and home theater systems today. I don’t see any reason why it would be different for Home Automation platforms.

JDRoberts · August 20, 2019, 10:08pm

Also, there is the issue of third-party standards.

Zigbee and Z wave are independent third-party alliances Which have created standardized protocols for Home Automation, which makes it much more likely that, say, a light switch from one vendor will be able to work With the hub from another.

You mentioned Wi-Fi: so far, although Wi-Fi has a standardized engineering protocol for the transmission of messages, it has not adopted a standardized home automation protocol for the content of what those messages might be. Each individual device manufacturer makes up their own message content. So a Wi-Fi light switch from one vendor will likely not work with another vendor’s app.

FAQ: WIFI Devices in ST? How can I integrate a WiFi or Bluetooth device that isn’t on the official compatibility list?

tgauchat · August 20, 2019, 10:20pm

Groups like this (Smart Home Automation Group) on Facebook are one source to hear about experiences with a range of platforms.

But there’s bias in the Groups from those who talk the loudest or most frequently.

Very odd that consumer electronics & home improvement media outlets aren’t doing a better job at professional reviews and education.

Franky, the best information you can rely on in this Community are examples of how powerful SmartThings is - and plenty of examples of hiccups and recurring or persistent issues too.

Not that we don’t know anything about the other options, it’s just that we obviously spend most time on SmartThings.

JDRoberts · August 20, 2019, 10:21pm

The subreddit on Home automation is good, too.

https://www.reddit.com/r/homeautomation

debugging · August 25, 2019, 7:11am

Developer POV (not consumer)

Recently implemented 4 platform Google SH Actions, Alexa, ST C2C and IFTTT with Oauth2 services. It’s been quite a bumpy road. There are still issues in each platform. Standardization goes as far a 1. incoming calls to your platform , 2. a callback into the platform. (“Eco system”) After that there is no standard. Sample code is scarce, documentation is jumping for one webpage to the other (where did PDF files and “spec” document go nowadays ?) You are almost completely on your own figuring things out by trial and often error. Quite challenging getting a device work with all platforms. Google just introduced smart home local execution (devmode) but it still needs the cloud and the Google device in your home is the master of all network transaction. (AFAICT).

The main reason I looked at ST is because it looked like ST devices could be run100% locally. (= “dream”). For sure if you can develop Zigbee or ZWAVE devices but access to those standard and hardware solutions haven been opaque if you can’t or don’t want to spend lots of $ on kits , licenses and hardware design + then the frequency bands are different per region (headachje) . So that is not so easy. Not sure yet if the ST rev 3 hub can be used 100% Wifi local only, that would be the best solution. I recall that was still in development ?

In general any WiFI device on all platforms goes trough the manufacturer + eco-system cloud because the big 3~4 (GAAS) Smarthome companies have no interest in users running things 100% locally with an open platform, though I believe and hope(d) ST will be the differentiator). They need your data and stay connected because you are the product. Sad but true, the GAAS companies don’t. provide 100% local solutions, that is what it call “progress” for the “modern” world . “You own what you use” is so old-skool (end of cynsim) (You still own CD’s :-)) … I do. I have been decades in tech , software and quite disappointed how tech developed in greedy tera-dollar software eco systems while apart from a few exception,s hardware (device) / ODM manufacturers almost don’t make a penny… This is one of the biggest inequalities in the “modern” world.

And now… IoT eco systems are s coming with other API’s from the GAAS group so the whole thing becomes a even bigger hard to interoperate spiderweb.

This is my simple POV. Like to hear other viewpoints !

DanielSiegel · August 25, 2019, 2:26pm

Is the concept of what I call an “external device handler” unique to SmartThings (as compared to Google, Apple or various other platforms/ecosystems)?

In other words, in SmartThings, the device-specific functionality lives EXTERNAL to the device (whether on the hub or in the cloud). So, the manufacturer of a device (eg, a light switch) creates that handler (and perhaps allows third parties to modify/replace it) to interface its device (and its own built-in firmware) with the SmartThings platform.

This external device handler determines not only the functionality exposed to devices on the SmartThings platform, but also (to some extent) the user interface in the SmartThings classic app.

Is this concept present in Google, Apple and other platforms?

If so, must a device manufacturer create this external device handler for each separate platform (without being able to reuse code because each platform has its own language and development environment)?

JDRoberts · August 25, 2019, 3:36pm

I can’t speak to Google, but certainly it’s available on Apple HomeKit and other Home automation platforms. Quite often it’s called “plug-ins,“ and they may be provided by the manufacturer or other community members.

Apple definitely has these.

https://developer.apple.com/homekit/

The Device Handler Concept

Before going into more specifics, I think we need to talk about the architecture a little more. I would have to somewhat disagree with this characterization of the whole concept:

In other words, in SmartThings, the device-specific functionality lives EXTERNAL to the device (whether on the hub or in the cloud). So, the manufacturer of a device (eg, a light switch) creates that handler (and perhaps allows third parties to modify/replace it) to interface its device (and its own built-in firmware) with the SmartThings platform.

The device specific functionality always lives in the device itself. The device type handler is simply a driver, just like a printer driver on a PC. It exposes certain functionality of the device to the platform and formats messages to the device in the expected format. But that’s all it is, a driver. If you add functionality to the DTH that is not in the device itself, it will not be performed. A printer which is black-and-white only will not turn into a color printer because you use a different driver. A smart switch which is only a binary on/off switch cannot be turned into a dimmer because you use a different DTH. If a battery operated sensor does not report battery levels, there’s nothing you can add to a DTH to get them.

The functionality is in the device. The DTH is the driver that allows you to process messages to and from the device to access that existing functionality.

That’s the same way that plug-ins work on other systems, like Homeseer or Vera, and that’s how apple’s development program works.

Amazon

Amazon does this through “skills.”

https://developer.amazon.com/docs/smarthome/understand-the-smart-home-skill-api.html#prerequisites-to-smart-home-skill-development

Cloud or Local

In general, local systems like homeseer, vera, or Hubitat Will run these drivers locally if possible. Cloud-based systems like Amazon, smartthings, or Homey Will run them in the cloud.

On the current smartthings platform, all custom code, whether it is a DTH or a smartapp, runs in the cloud. Only a few stock Features, basically smart lighting and some bits of smart home monitor, can run locally. Even the app cannot communicate with the hub locally. This is true for all hub models.

https://support.smartthings.com/hc/en-us/articles/209979766-Local-processing

Responsibilities of the Device Manufacturer

If so, must a device manufacturer create this external device handler for each separate platform (without being able to reuse code because each platform has its own language and development environment)?

In general, yes, because the way in which custom drivers are utilized varies by platform even if they are using standardized message command sets.

There are a few exceptions.

If you want a system with very similar code to smartthings that does run locally, look at Hubitat
if you have a device certified to one of the third-party home automation protocols, such as Z wave or zigbee 3.0, then you can assume that any hub/controller certified to that same protocol will have a “generic“ driver that will be able to access the basic functions of your device. So if you manufacture a simple open/close sensor or a standard dimmer using one of these protocols, you as the manufacturer do not need to provide a driver for your customers: Their hub should already work with it.

That does not mean that a device intended to work with HomeKit will suddenly work with Z wave. Those are two separate protocols. It just means that a device intended to work with a certified Z wave hub should work with any certified Z wave hub at the basic level.

Note That the plugin structure is typical of home automation platforms, but is not typical of home security platforms. Home security systems quite often want to lock everything down to just a few specific device models using only drivers that the company itself provides. That’s intended to manage both reliability and security. ( it may also be part of the business model.) so all of the above in this post applies only to home automation systems, not systems sold primarily for home security.

JDRoberts · August 25, 2019, 3:16pm

It cannot. It is still a cloud-based system for most things. Even the app cannot talk to the hub unless the SmartThings cloud is available.

tgauchat · August 26, 2019, 9:16am

What hat did you pull this out of? Never has SmartThings implied any such functionality.

Though SmartThings has been taking some steps to increasing resilency and performance by putting more and more Device Type Handlers into the Hub firmware for local execution; there still is very little automation that can be done locally - the biggest positive example is Smart Lighting.

Samsung SmartThings has given zero indication they want to give the App(s) local execution, nor any specific plans for SmartApps (such as, for random example, Amazon Alexa - given that new Echo devices have a certain amount of local speech recognition and processing power now).

SmartThings is and has always been (and will likely always be, a “cloud-centric” platform. So is Gmail, Facebook, Netflix, Spotify, …

They envision “the internet” as a utility - as reliable as (and with performance improving as) electricity, gas, water, and telephone/cable. It is a reasonable vision.

Why not more focus on local? Well - there are certain technical advantages to Cloud - and certainly plenty to distributed local (“edge” or “fog”) too. But ultimately, the value is in the data. Samsung is no different than Google and Amazon - they want your data. They want to provide frictionless data capture and consumer behavior modification. No sure sure about Apple, but … probably a lot of the same with just a different marketing spin.

debugging · August 28, 2019, 3:06am

OK, I must have incorrectly assumed the ST app “talking” to the hub directly. Google is implementing local execution which will go into production in October which basically takes out the middleman (= device manufacturer cloud) except for initial setup. Same trend is happening with AWS IoT. AWS reason/ argument / excuse for this is that all that smarthome 3rd party cloud integration was quite complex for device manufacturers. So, the “Device manufacturer” release the code and smarthub companies load that code into the device. What’s thus left is for those to make it 100% (non voice) local is the app to talk to the hub directly over Wifi. (The internet would then only be still be needed for Voice to Text) Let’s hope ST comes up with something local similar.

JDRoberts · August 28, 2019, 5:20am

It’s a fairly limited feature. What they’re offering will only work for WiFi devices which are on the LAN. And even then only some.

The app fulfills smart home Action requests by sending control commands to the smart device through application-layer protocols, including HTTPS, TCP, or UDP.

They don’t have any local execution for zigbee ( which echo plus has now) or zwave (SmartThings has both).

And they don’t have any local execution for devices which require TFA.

https://developers.google.com/actions/smarthome/concepts/local

I’m not saying it’s bad, it’s not. But it is limited. Smartthings currently has some local execution for some devices, it’s not that different.

JDRoberts · August 28, 2019, 3:58am

Apple’s a bit simpler: they want your upfront money, not your data. They sell premium hardware and premium services. And of course take a significant cut from their app marketplace. But it’s all at point of sale, not by monetizing your data.

tgauchat · August 28, 2019, 8:19am

SmartThings has given ZERO indication that this is the direction they are headed in.

“Fully local” (especially if that definition is to includes App control) has never once been mentioned as a SmartThings goal. Automated actions like “turn on lights upon motion detection” already exists (supported devices + Smart Lighting); and “turn off valve upon leak detection” … I think exists (SHM/STHM) but with further complications - i.e., no way to disarm this rule without the Cloud.

jody.albritton · August 28, 2019, 8:32pm

Come to SDC 2019

625alex · August 28, 2019, 9:14pm

Did you think for a minute that he’s not going to come?

debugging · November 25, 2019, 5:37am

Was there anything exiting announced for local execution ? My interest is for C2C Schema devices.

tgauchat · November 25, 2019, 8:06am

C2C literally stands for “Cloud to Cloud”.

The concept of “local execution” for a Cloud Scheme Connected device is an oxymoron.

The C2C scheme is a “shortcut” for businesses to integrate their existing “cloud connected” devices (i.e., any device that is controlled via an App, web page, IFTTT, or non-local Alexa, Google Home, etc.). While some such devices will find the device locally (i.e., on the local LAN WiFi), in order to make them reachable while away from home, and permit various simple automations (e.g., scheduled control of a WiFi lightswitch), such businesses run a Cloud to manage the device - and provide an API into that Cloud for other platforms to access. Since that Cloud exists, most vendors do not provide a local API. Philips Hue is an exception, for example, because it has a local IP based API and SmartThings connects to it via the LAN connected to the Hub. This is the case with any “Super LAN Connect” device, including Sonos too.

TP-Link KASA (and many other WiFi bulbs/outlets), various WiFi Garage Door controllers, etc., etc., are C2C based, and are unlikely to become qualified for local execution, unless these businesses change their technical integration strategy.

Some vendors are worse. Wyze Labs for example, could offer a direct Cloud API to their new sensors and bulbs, but instead have only tied their API directly to IFTTT. As such, these devices are not even C2C integratable (and, again, definitely not local execution capable).

The new C2C is tremendously valuable as it simplifies SmartThings integration with the quickly growing WiFi device segment … since most such devices have a Cloud. Such integrations are sub-optimal for performance because physical Event Messages must go from your home to the vendor’s cloud to the SmartThings Cloud to your LAN and then to the device (or vice versa, etc.).

debugging · November 25, 2019, 10:06am

C2C takes a lot of work for device vendors , sometimes are unreliable, sometimes insecure. They need to integrate device with multiple eco-systems/ API’s as well. Google/Amazon realized that, now they are moving into the direction that that devices interact (authenticate, talk, command, send status, and update firmware, ) with their cloud directly . Google’s local execution is a first step. The Amazon Alexa Connection kit and IoT infrastructure is a even better proof. It looks like the ST new “direct connection” (now the term IoT devices is used) is very similar. The trend clearly points taking out the middleman (“vendor” cloud) in the device control and management process. In return, vendor thus pay for convenience with losing (direct) control of their devices having to monitor and manage the devices from AWS/Google cloud ($$) This also could be considered “lock in” for vendor and user to those eco-systems. In theory C2C could be gone in the long term if those platforms wish to do so.
However the "hardware lock-in " approach has a problem for vendors . In case vendor want to support multiple eco-systems with their hardware it becomes hardware/firmware wise very complex or expensive.

It would have been nice if the mobile app could control the hub directly on the local network. Wifi device could expose themselves to the hub via Bonjour (alike Google) and ST cloud could control them via the ST cloud. Some plumbing would be needed in the background to link the device with the vendor cloud as the vendor cloud may wish to know the status change of the device on the hub . ST could simply add this in the Hub firmware using the same kind of call to the vendor cloud as the the vendor cloud does today with a C2C device state callback call. Thus local execution but now from the hub to the cloud instead the other way around.