There is really no difference. ST->Alexa is cloud to cloud and Notifications rely on the ST cloud. Just a reminder of the current ST architecture courtesy of @JDRoberts
2 Likes
Exactly. But the point Iām trying to make is, with so much discussion on ālocalā or ācloudā, is it really important whether a routine that triggers and runs locally should have the last action in the cloud? Does that make any difference to the user?
Or is there more to itā¦rules donāt have notifications for example.
My experience so far has been that local actions execute more quickly which makes other things better. Lights that I had mirrored with the old SmartLighting app would often take several seconds to go on/off. With Routines (or Z-Wave association groups), mirrored lights turn on/off nearly simultaneously. And if I have any Internet fade, my local automations do still run without the connection to the cloud.
But, in the end, ST is a mainly cloud based system and you have to evaluate whether thatās an issue for your needs. If so, there are other home automation solutions that have greater local autonomy.
1 Like
The Third Reality sensors are new and SmartThings possibly doesnāt have the firmware files yet. Hubitat only just got them.
However, SmartThings has the firmware files for classic Centralite devices like the Iris v2 and v3 sensors. In fact, only SmartThings has them (as Centralite went out of business before Hubitat could get the firmware).
Echo That!
2 Likes
@SmartThings I know Iām late on the ball here, but why did you think it was wise to discontinue Groovy code and break hundreds of 3rd party Smart Appās and Device Handlers in the process. If it aināt broken, donāt fix it!
Because they were continuing to have to scale up the cloud hosting service to support device handlers and SmartApps and it was costing them a lot of money. The goal was to move to an architecture where device handlers (now Edge drivers) are running locally which decreases the dependency on the cloud. For SmartApps, the architecture provides hooks for ST to interact with 3rd party applications that will now be hosted by those 3rd parties.
There has been plenty posted in the community over the last couple of years about the motivation for the transition. At the end of the day, hub-based ST users account for a very small percentage of those who use ST today. And of those who are hub-based, a large percentage have a dozen or so basic devices and these changes are completely transparent to them.
Yes, itās a pain for those of us who have more sophisticated home automation environments, but I think weāre in the minority of ST users and that was certainly factored into their decision.
On the bright side, at least there is a platform transition direction and they didnāt just pull the plug on supporting hub based home automation.
6 Likes
@h0ckeysk8er Fair play, but then why not give people the option to run Groovy code locally, either on the ST hub if itās powerful enough or on a normal computer talking to the hub?
ST without a hub to provide Z-Wave and Zigbee support amazes me and seems a tad strange as I moved over from X10 to ST in 2016. If most people are hubless, what are they using to control lights, appliance sockets, fixed-wired switches, sensors, etcā¦
WiFi, Samsung devices, cloud connected devices. Devices are connected by various technologies and Samsung is trying to position competitively so that Google and Amazon are not the only players in the market.
1 Like
That is rather begging the question. They probably arenāt doing those things. Those that do would be proportionately more likely to be using hubs, but I suspect the hub users would be outnumbered by those who started with a Samsung appliance and added a few cheap WiFi devices.
2 Likes
There was a post long long ago from Smartthings explaining that Microsoft had bought the IDE servers, as Samsung did not want there technologies run from Microsoft services (at the time) they decided to move away from the IDE and Groovy
Subsequently Lua was decided it was the best language to move to which then led to the advent of edge drivers
Edge drivers were then touted to be easier for users rather than the (complicated) Groovy drivers and IDE
I remain highly sceptical about the whole deal, to me it seems to be the beginning of the end for 3rd party integrations and a move towards Samsung only products
1.IDE groovy gone, completely removing user created integrations
2.Samsung stop producing hubs
3.Samsung replacement drivers limited to the basics and a small subset of what was once available, community developers picking up the slack
4.Zwave not available on the new charger/striped down hub
- Smart apps are available but only Samsung smart apps, there are a few user created smart apps but they are not for the general public and easily implemented
6.The app has morphed into a restrictive design giving developers and users little or no options on device control, what can be achived now is NOT as extensive and user friendly as it used to be
The upshot from my limited view perhaps is that Samsung is funneling home automation into something that is Samsung only devices
Without our current community developers, Smartthings the app would no longer be of any use to 90% of hub usersā¦ 
You could argue that there are now more devices available to control than before, true but only because of 3rd party community developers who have run with an opening, how long before that gets deprecated but with Matter on the horizon and available in a very limited and complicated way right now, Zigbee and Zwave are looking doomed, just not publicly
The option exists to run Groovy code on Hubitat, either as a replacement for your SmartThings integration, or in parallel, as I do.
4 Likes
Many options these days, although as @orangebucket noted an even larger group probably donāt have any of those. Most āSmartThingsā users have a Samsung smart television, smart appliance, or smart vacuum. Many have a Galaxy phone and some have a Galaxy smart tag. That group alone is millions and millions of people, far more than those that have a hub.
But beyond them, you can have quite a nice hubfree environment with a ring doorbell, Arlo cameras, Nest or Ecobee thermostat, any of several WiFi light switches (including ones from Meross, TP Link Kasa, or even Leviton if youāre in the US), smart plugs (again from TP Link Kasa or Meross), sensors from Shelly (theyāve done remarkable things working with SI labs on improving the battery life of small Wi-Fi devices), Yale or Schlage WiFi smart locks, even inline UL listed WiFi relays from Shelly.
https://www.shelly.cloud/en-us/products/switching-and-triggering#unfiltered
All of the above have official SmartThings integrations and work out of the box without custom code required.
And all of thatās without Matter, which will eventually bring even more hubfree choices.
Add the Thread Border Router inside many smart speaker models these days and that will open up another whole set of easy to install choices once Matter is widely deployed.
So the real question is why have a SmartThings/Aeotec hub if you donāt already? Right now the only answer is Zwave or zigbee devices without another hub.
Choice is good, and there will certainly be people who choose that option. But they are a small percentage of a small percentage now.
Iāve been trying to think of a device class (not protocol) that isnāt available in a hubfree option. The only one that comes to mind is batterypowered rotating valve shutoffs. They just use too much power for current WiFi to offer a suitable option right now. There are dumb mainspowered ones that you could run off a WiFi or Thread smart plug, though, so itās really just the subclass of batterypowered thatās missing. At least until somebody makes a Thread version.
But everything on your list can be done now with mass market products currently available.
FWIWā¦.
3 Likes
To be honest I think I was being a little harsh with my OP and most of my devices still work, all that has broke is the Hive Integration and I only use it for the Lighting side with SmartThings, for that I may move to something like Philips hue or similar.
That being said, I hope ST keeps with support for 3rd party integrations whilst keeping support for Z-Wave and Zigbee; thatās why I invested in ST in the first place after I got fed up with X10ās weakness, mainly prone to interference, lack of stylish/discrete products, and overall archaic nature of a 70ās automation protocol.
3 Likes
Is that a fact or your personal suspicion/prediction on the future?
A diverse centralised communication protocol platform like Z-Wave and Zigbee is king to me, I have 30 Z-Wave/Zigbee devices in total inc remotes. About 80% Z-Wave and 20% Zigbee.
Itās a fact. The new Samsung station hub offers Zigbee, Thread, and Wi-Fi, but no zwave. This has been much discussed in the forum and in blog reviews, but itās admittedly not obvious from the product description except for the absence of the Z wave logo.
Some Community members already have it. Discussion in the following thread.
2 Likes
Yes, itās a fact. Itās been widely discussed that the SmartThings Station does not have a Z-wave radio. No need for a prediction as itās shipping now.
3 Likes
Same with my ST fridge Family Hub - Zigbee and Thread with the ST Dongle added, Matter and Wi-Fi native to the fridge. No Z-Wave.
Will be the same situation with the TVs.
1 Like
Device execution might happen locally, but I donāt see a decreased dependency on the cloud. Everything still updates the cloud on each event. It still seems a cloud based architecture.
2 Likes