SmartThings is Dead

Yikes!

I hadn’t seen that before, and I actually found it very depressing. This is still a cloud-based system. (“Hive” is the hub and “Swarm” is the cloud.)

Hive
.
The brains of the Rule Engine that contains and is responsible for the majority of the Rule execution code, Hive has two main functions: expose an API to execute Rules and provide an interface for parent services to interact with the platform.
.
To reduce overhead, Hive is dedicated to executing Rules, trusting the parent service to provide contextual data needed for rule execution, such as device states or location modes. For example, when a parent service receives a device state change event, it invokes Hive to evaluate (for example, is equals condition true ), and executes the Rule.
.
Swarm
.
The cloud container for Hive and management of I/O functionality for cloud execution, this service is deployed to the cloud and listens to events from the SmartThings event pipeline. When events are consumed, Swarm invokes Hive to execute Rules. The implementation of Hive’s interface by Swarm is a set of HTTP clients that interact with the SmartThings API.
.
For example, when Hive requires a device state to evaluate is equals condition true , Swarm dispatches a GET request to the Device API and forwards the state to Hive. Similarly, when Hive needs to send a device command, Swarm dispatches a POST request to the Device API.

They are claiming this reduces overhead, but it clearly adds it. You don’t need to go to the cloud to get the device state. (HomeKit doesn’t, Homeseer doesn’t, Home Assistant doesn’t, Hubitat doesn’t, Vera doesn’t, matter won’t on most platforms.)

@Automated_House and I were just discussing today in another thread the fact that right now scenes don’t run local even if all the devices in them are eligible to run locally. If I’m reading this link right, scenes may never run locally. Which is tragic.

Maybe I’m misreading it. I honestly hope so. But that is not a description of “edge computing“ in the more general sense as it’s being used today in the home automation industry. Edge computing is supposed to move as much of the processing as possible as close to the user request as possible. That’s not what this design shows.

Right now, HomeKit requires a Meross Smart Plug to be able to run without the Internet and to operate on the local LAN. SmartThings requires the exact same device in the same home to contact its cloud and have that cloud contact the smartthings cloud to update state. No way is that “reducing overhead.“ And again, if I’m reading this right, that’s the way it will continue to operate in the new swarm/hive/drone paradigm. But again, maybe I’m wrong, and I hope I am.

It definitely doesn’t comfort me, though. :thinking:

4 Likes

Over 90% of the CURRENT SmartThings user base runs without a hub, because it’s a requirement now for every Samsung smart appliance and smart television. They may be demanding stability, but they haven’t gotten it yet, and it’s been two years.

Samsung sold 11 million smart tv’s in one quarter in 2020. They’re all already SmartThings customers, and only a small percentage also have hubs…

1 Like

We are working from the same blogs of course, but my read on it is that Hive is the rules engine and can run on BOTH the Drone/Local and Swarm/Cloud. I believe the thing that dictates where the rule run is whether or not they have devices implemented as edge drivers or if they were setup with the cloud schema connector.

See this in their post:

Rule Engine

End-to-End, the process looks something like this:

Rule: If Switch A is ***ON*** , set Switch B to ***ON***

1. User turns *Switch A* on
2. Swarm (cloud) or Drone (hub) receives the ON event
3. Swarm/Drone tells Hive to execute Rules with *if Switch A* is ***ON***
4. Hive evaluates the Rule Conditions and determines to be **true**
5. Hive then evaluates Actions, set Switch B to ***ON***
6. Hive says, “send device command to switch B”
7. Swarm/Drone receives “send device command to switch B” and executes the request

Looking at #2, the ON command can come in through either the cloud or the hub. Cloud could be from another integration or an app. Edge would be from a local device. I think is is based on where the events originate. In #3, Hive runs the rules, but Hive runs in both the cloud and hub. This blog post explains their tech choice since the same code runs in both via a container.

Also check this out:

Drone invokes Hive to execute Rules when events are consumed locally on the Hub

I think I have this correct, but we are both looking through a keyhole until they roll it out.

1 Like

I think you misread it, though the diagram doesn’t really help. It probably helps to think of a Borg like ‘hive mind’ rather than a beehive.

My reading is that ‘Hive’ is the core of the Rules Engine and is implemented in the cloud and on hubs. The ‘Swarm’ is the container in the cloud using API calls to service the cloud Hive API. The ‘Drone’ is the container in the hub plugging into hub services to service the hub Hive API.

3 Likes

Imagine that consumerism is not the main problem with Samsung.

But Samsung is demanding you to change your phone, your TV, your washing machine, your fridge every two years! Because they stop supporting it or producing spare parts, etc.

Just imagine when you have to change your TV, which functions as a hub and you need to start from scratch again…

3 Likes

Haven’t been Scenes moved to the Rules Engine? I thought that was the point? Or was it just a move from the old groovy based system to the new API based one?

I can remember there was a discussion about it as it didn’t go seamlessly. For me colors were screwed up…

Edit: Sometime at the end of 2020 or beginning of 2021, there was a migration for Scenes to the Rules API. I cannot find the exact thread were it was discussed but there are breadcrumbs all over the place…

1 Like

My understanding is that the Rules API had a predecessor that was used for Scenes, and then they migrated to the Rules API with the Routines. So on the face of it they should be capable of local execution.

Scenes are a bit of a one off as they are managed like Routines as a private plaything of the mobile apps, yet they retain their own API endpoint and are mentioned separately in the developer docs (Routines aren’t).

Funny though that you are in the process of building some edge drivers for your Philips Hue Lighting Groups and your Bond Bridge, but meanwhile saying that Home Assistant won’t be able to do something smoothly.

Both the Bond Bridge and the Philips Hue Lighting Groups are supported out of the box in Home Assistant for a long-long time. And the Hue integration is blazing fast, plus supports all the devices on a Hue bridge (including remotes, switches, motion sensors).

Someone summed up recently his experience with both sides of the fun and how it works:

They went to the Rules API, but my understanding from others, including @Automated_House , is that they still don’t run locally. :thinking:

2 Likes

correct. As @orangebucket said, they have their own API endpoint thay must not run local.

2 Likes

Again, I am not talking about right now. I am talking about the future when ST takes Edge out of beta, adds Matter support, and possibly turns on the Thread radio that is already in their hubs. Once this happens, it will make for a pretty competitive platform supporting local and cloud devices.

Not all users are interested in building a dashboard as the culmination of the smart home. The idea for ST, that I agree with, is that it is about integration of the home with all sorts services, devices, and appliances. These aren’t limited to being inside the walls of the home. This architecture that supports both local and cloud will allow it to connect to a broader array of services.

Lastly, it will be more user friendly than Home Assistant for people that aren’t super tech savvy. Just about anyone can pickup ST and connect it to their appliances and some cloud services. Once those same users can easily setup local devices with Edge/Matter, I think the platform will takeoff.

With the current pace it will happen maybe in 3-5 years time.

And those users are coming here to ask questions why I cannot do this and that, why it is never updating, why is there an error, etc…

1 Like

Different systems will work for different households. Each has pluses and minuses, and I don’t see any one on a trajectory to become the hands-down favorite at this time.

Smartthings has already announced that it is only going to provide a one-way integration to Matter: that’s going to limit adoption somewhat. But it will always be a top-tier candidate for the millions and millions of people who buy Samsung smart televisions and appliances. So that’s significant marketshare right there.

If they manage to deliver on what they’ve already defined for edge, it will certainly be a better system two years from now than it is today, assuming, as always, that they can fix the reliability issues.

But there will still be many people who prefer home assistant, or HomeKit, or hubitat, or homeseer, or Homey, or Abode or Aqara or Smart Life: there will be a lot of choices, and that’s a good thing. And there will always be some people who choose to run two or more platforms.

Smartthings still has a more consumerfriendly app than home assistant or hubitat, but SharpTools can fill in a lot of the gaps for hubitat. And HomeKit’s app will be better for many people who already have an iOS device. (Obviously not for those with Android devices, of course.)

So lots of choices, very real difference in feature sets, lots of reasons to choose one platform over another but those choices will still be different for different people. And that’s not a bad thing either. :sunglasses:

4 Likes

I’m genuinely curious why you are in this community, especially with a “Community Master” label. Isn’t the point of the community to help people apply it to their use cases? Seems like you are more interested in driving people off the platform. I’m personally encouraged by the direction which is why I hopped in on ST. I’m sorry if you aren’t satisfied with it. To get back to the OP, I certainly don’t think the platform is dead.

A person can be very helpful in the community and still feel frustrated with the platform from time to time. As is true of many platforms.

6 Likes

I agree with JD, I criticise the app to within an inch of its life, it should be taken out back and shot, if it weren’t nailed to the perch it would be pushing up the daiseys

BUT I use ST and enjoy it, it is useful to me

ST as a whole is not dead, annoying, frustrating but definitely not dead

4 Likes

To be honest, the current App is still way slower than when I first came on board 5 or so years ago. However, if I was first coming to ST “today”, I would say that it’s a solid platform that has issues here or there. It really is a different beast as before and I’ve been here through the good and bad times. I purchased a Hubitat Hub which died after a couple of years and now have the latest Hub but still just can’t get with the program because I have WAY more delayed triggers, batteries draining and overall poor performance from Hubitat than I do with ST. The possibilities with ST is not as open as it was say 3 years ago but still, not dead by a long shot.

I just hooked up my GE Washer and Dryer to ST via IFTTT and it would be perfect if there was an “On” trigger from the GE Smart App which is no fault to ST. Sometimes people blame ST for other manufacturers lack of features. Honestly, most of my past woes were self inflicted. Just bad rules or codes that were causing issues. ST shares some of the blame but can say that things are much better now then they were a while back.

I have quite a bit of devices. Since Alexa is my main input interface, I hardly use the App because everything is…automated.

3 Likes

Imagine your home automation system built by a company that really wants to sell you new devices every few years. It’s a horror: a Samsung 2018 TV that used to be supported is no longer supported. I don’t need to replace appliances like they are cell phones. In fact, I kept my Samsung S8 for 4 years… and it wasn’t replaced with a new Samsung.

2 Likes

That’s the point I am trying to make. By implementing the Matter standard, they are moving toward an interoperable model rather than brand lock-in. Currently, ST has special support for their appliances and devices. Once they implement Matter in those future devices, then anybody could support them (Google, Alexa, etc.). If they drop support, you can take your device elsewhere. However, if they are implemented to an industry standard, they will be much less likely to drop support at all.

Sounds Great, but it’s not going to work that way. As always, the devil is in the details. :smiling_imp:

  1. The matter standard does not include appliances. At all.

  2. matter support works in two directions.
    a) incoming. Devices which are matter compliant will show up in the smartthings app and can be included in smartthings routines. This is what smartthings has announced support for.
    b) outgoing. Devices will show up in other matter compliant apps, either individually or through a “matter bridge.“ SmartThings has specifically announced they are NOT going to do this: A smartthings/Aeotec hub will not be a “matter bridge.”

There are some other hubs who are going to act as a “matter bridge,“ including the Philips hue hub and the aqara hub, quite a few who have not yet announced whether they will be one way or two way integration, and SmartThings, who so far is the only one that has announced their integration will only be one way.

So what you have described would be great, it’s just not what’s going to happen.

See the following discussion thread for specific details on Matter integration for SmartThings and others: there are quite a few of us who have been following this closely.

Matter - smart home connectivity standard (formerly Project CHIP)

4 Likes