Goodby SmartThings, goodbye Samsung

[quote=“JH1, post:40, topic:66375, full:true”]Say what?

I don’t see that happening. The cloud is their compute infrastructure. If they are going to localize compute for us (praise be the lord if so), it would make sense to offer on some other compute the hub talks to over IP… but I suppose it could be a USB, just not seeing the advantage to doing USB. Not a lot of compute heavy USB that I am familiar with.

In any event, I doubt ST is motivated to localize compute, I think the cloud is their model for a reason (data mining, what not).
[/quote]

At some point in the not-too-distant future, the current generation of smart systems will become outdated as new and smarter systems roll in. At that time, Samsung will have absolutely no interest in retaining cloud services for us. I’m hoping that, for those of us who like tinkering, there’ll be a way to retain ST as a development platform… I’m merely suggesting one method by which that might occur.

If ST were to play a part in enabling us to tinker with the platform in that way because it became legacy, it would dump the code, which runs in AWS today to the public. Easiest way to operationalize that since it runs on intel today is pick your own intel arch compute and go crazy. Again doubtful that would be a USB.

But this is crazy talk. Samsung isn’t ever going to do that. If they see it as legacy, they will have a stake in or could see a possible future stake in whatever the next generation of Smart Homes tech there is and they will have no interest in enabling folks to remain on older technology.

In many ways ST could just be superseded by AWS IoT directly. Did you see the Greengrass thing they announced last week?

Local compute, messaging & data caching for connected devices.
Run IoT applications seamlessly across the AWS cloud and local devices using AWS Lambda and AWS IoT.

But only devices capable of running the AWS IOT SDK.

AWS Greengrass lets you build IoT solutions that connect different types of devices with the cloud and each other. Devices that run Linux and support ARM or x86 architectures can host the Greengrass Core. The Greengrass Core enables the local execution of AWS Lambda code, messaging, data caching, and security.
.
Devices running AWS Greengrass Core act as a hub that can communicate with other devices that have the AWS IoT Device SDK installed, such as microcontroller based devices or large appliances.

That’s not your typical battery operated contact sensor, and it’s not a mesh protocol.

It’s Not like you could just swap it out for the SmartThings cloud. It’s not going to be the same devices and I don’t think it’s even going to be the same device classes.

True, it couldn’t talk to your zigbee or zwave devices directly, but a raspberry pi with zigbee and z-wave radios could more or less be an opensource hub.

There is an effort for both Z net standards to adopt IPV6 connectivity

If that happens… then things can essentially be hubless… if you will…

I wouldn’t hold my breath. That announcement is almost 2 years old. Not much happened since then except perhaps Nest’s CEO getting effectively fired. :wink:

Hey guys-

I wanted to post a final message to this thread for anybody who might find it months from now.

I’m finally happy with the performance of my ST system and I’m keeping it. Here are a few of the issues that got it working properly for me.

PROBLEM:
Z-wave network weirdness. In my initial setup I ended up moving several z-wave devices around and generally adding things until I got devices positioned where I wanted them, and got the coverage in all rooms that I wanted. I think this is probably a typical growth scenario with HA. What happened however was that the z-wave network routing became corrupted. I clearly had devices routing incorrectly, especially battery powered ones, and had a few “phantom” devices that had been removed, but were nonetheless in the route path for other devices. This was causing the network to drop messages, which resulted in weird, intermittent behavior.

SOLUTION:

Unplug the hub and remove the batteries for at least 15 minutes so that all child devices “forget” their associations and routing is rebuilt from scratch.

Make sure battery powered zwave devices were awake and stayed awake long enough to be included in the z-wave network repair.

PROBLEM:

Crappy logic using SmartApps or using the third party rules engine, SmartRules. Neither solution offered enough logical primitives to do what I wanted to do. The result was a mess of convoluted work arounds using SmartRules, SmartApps, and Routines that often ran into each other and produced weird results.

SOLUTION:

Move all logic into CoRE

PROBLEM: devices mis-reporting state, failing to report state, or failing to report in a timely manner.

SOLUTION:

This is more easily addressed once the network and programming are working properly. Still somewhat of an issue with a couple of devices- A lock, contact sensor, and humidity sensor specifically. The solution here is either to replace the devices (the lock specifically in my case), or reconfigure the device to report properly (humidity sensor, and still working on it). As for the contact sensor, it’s outside on a gate and I’m guessing my attempts at waterproofing it have something to do with its behavior, so I’m not too concerned about it.

Anyway, that’s about it. I hope this is helpful to some future SmartThing pioneer. Getting the z-wave network straight is of particular importance, but there are few tools with which to see and diagnose problems so you may not know you have an issue.

Have fun!

4 Likes

Glad you have it working!

Just one technical note… The unplug for 15 minutes protocol applies only to zigbee devices. Z wave devices don’t care if the hub goes off-line. That’s why you need to use the Z wave repair utility to fix the addresses for those. :sunglasses:

6 Likes

Since the last hub update, I’ve had all sorts of stability issues with routines and automations failing to launch. It also fails to register that I’ve changed an “off” time in a switch automation. It still turns off at the old programmed time while the automation happily shows the new time.

SmartThings will not move beyond a handful of egghead tinkerers so long as the platform requires constant workarounds and problem solving to reliably accomplish simple tasks.