interesting- i thought i read they had issues with v1’s and people doing things “at sunset” becasue too many devices needed to do something at once. I always thought that the point of amazon elastic cloud was that you didn’t need to figure out how many servers or whatever to source- that amazon constantly adjusted what they provided you based on need? I thought it was a way so that if you went on sharktank and went from 2 customers a day on your website to 2 per second amazon would just deal with it.
Sorry for my ignorance- just trying to learn. So they could just write their application to request additional resources at sunrise and sunset and then “give them back” right after? If so why dont they- cost?
OR once you request more do you get stuck with them - there’s no giving back?
The architecture has some stress points, and while what you are saying makes sense, it is easier said than done. There has to be a server linked with your hub. It’s not really possible to change that link on the fly. So for a given server, it is vulnerable to spikes in event traffic from all of the other hubs linked with that server. They have work to do…
FWIW, as of last December, Vera iOS app has full iPad support, including landscape mode, as well as Apple Watch app, while SmartThings still does not have iPad version of the app. Also, Vera’s Z-Wave implementation is more solid and compliant than SmartThings’, which always seemed like an afterthought.
Well… the same is true for SmartThings since the V2 launch debacle. So, I guess the field has leveled now.
and it is impossible to scale with amazon’s servers system instantly. it takes time to ramp up and by that time the Sunrise/ Sunset window is gone.
Honestly, I am not surprised they are having problems now with this new info. Amazon’s setup is not very stable for real time stuff like this. They need to spend their samsung cash on real servers at key locations.
Wouldn’t engineering it to scale up prior to predicted peaks occurred and scale down as the volume slows make sense?
Yea. I think it would. What wouldn’t make sense is to scale a system to not be able to handle your peaks and let crap overflow and collapse on on regular basis.
And certainly nothing is instant, but you can have power on tap in a properly scaled load balance cluster.
Whether it’s a priority or not is ultimately up to you guys, but it seems like a surmountable engineering challenge if prioritized enough to allocate a dedicated team to. If the hub itself isn’t powerful enough to run the groovy interpreter, databases, rules engine, etc., then why not package up the backend and allow people to run their own SmartThings servers or caches on the LAN? (Of course, that would limit the market much more than doing it on-device, and may only be a bridge to Hub v3, this time with local processing for real). You could even opensource elements of it and benefit from community development in your own internal implementation of it as well.
That seems like the only way to permanently deal with the recurring reliability issues. Otherwise there will always be issues with people’s home internet connections, even if every server and network reliability issue on SmartThings’ end magically goes away.
Staples Connect is worth studying here, as their device (the Staples Connect D-Link Hub in particular) is rock solid. Their failing is that their platform is so incredibly limited in capability, and devoting attention to Staples Connect in general doesn’t seem to be one of Staples’ priorities.
I think SmartThings (or perhaps Samsung…) is underestimating the importance of this: IoT is currently “early adopter”, as I’m sure you’re aware. The world is waiting for a reliable home automation system to standardize on so that IoT can reach “mainstream”. Unless SmartThings gets local, it will never have the reliability to be that system, and the world - including your current customers - will standardize around something else. You will be Friendster at the arrival of Facebook, when you might have had a chance at being Facebook. Local processing is a pretty important investment in SmartThings’ future as a hedge against competitive action, even though the market need may not seem to be there yet. It’s one of those things that’s perhaps not totally apparent from a traditional market analysis, but painfully obvious when taking a step back and looking at macro-scale trends in the industry.
Most of the time when this sort of thing happens, it’s not a failing of the underlying servers so much as the network architecture (e.g. insufficient load balancing or caching), or the software coordinating them (e.g. cascading effects when nodes go down, or new caches needing to warm up at inappropriate times, or traffic stampedes due to synchronized activities such as firmware updates without staggering). I’ve seen this sort of thing many many times in the past. Usually in postmortem documents. Sometimes the problems are truly unanticipated, but too often they’re the result of unpaid tech debt that the company is moving too fast in some other direction to bother fixing.
Because SmartThings is essential part of Samsung’s Smart Home B2B cloud platform that intends to provide Samsung business partners with real-time access to home appliances and other customer’s equipment. Therefore all transactions must go through the cloud. No cloud, no money. Plain and simple.
SmartThings is really a real-time control system. There’s theoretically no way that this can be accomplished via the cloud. The control system must execute locally to avoid all the latencies and dynamics that can occur on a network.
There can be a coordination between cloud services and local services. All the device definitions, code compilation, and groovy interpreting can be done in the cloud, not real time. The result of all this processing would be an “executable” unit downloaded to the hub. The real-time control system execution on the hub can utilize “byte code” or simply a group of tables that specifically define the actions that should occur. The actions would include sending notifications of the current state to the cloud. Note that these notifications are not mission-critical and can tolerate network and processing delays.
I have to give SmartThings credit where it’s due. Regardless of what I think about their business strategy, their technology is quite remarkable. Their cloud response time (when it works) is amazing! No more that 100 ms, usually less. It’s actually faster than local Z-Wave communication between the hub and a Z-Wave sensor (which is a half duplex at 9600 bps). The reliability of the Internet connection may not be super high today, but it’s getting better. In a few years most metropolitan areas will be wired by super hight-speed optical links with 99.999% reliability. Connectivity will not be an issue. The biggest challenge that SmartThings is facing is load balancing and handling peak demand (event storms).
I respectfully disagree. If you give users an option to run everything locally, you cannot stop them from disconnecting the hub from the cloud and thus cutting off the mothership from its revenue stream. SmartHome cloud advertises real-time control of appliances. For this to work, the hub has to be tethered to the cloud 24/7.
2 Likes
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
179
Yah… there are dozens of variations that are possible to consider and discuss in the theme of this Topic … for example, the Hub could be programmed to refuse to work longer than 24 hours if disconnected, etc., etc…
But it is 100% true that SmartThings has zero intention of ever moving away from a “cloud-centric” approach (the exact definition of which is subject to some variation). Whether this is a strategic business decision, marketing decision, fundamental architecture inertia, or technical debt is probably irrelevant.
Remember, this is the same company whose CEO said it took him less than 2 or 3 hours to migrate 200 devices from Hub V1 to Hub V2 (ahem, not including migrating SmartApps / automations, groups/rooms, button controllers, etc.). In other words, top management does not live in the real world. I’m being inflammatory, perhaps, but not excessively exaggerating. As said earlier in this Thread …the Cloud is actually not the biggest problem at SmartThings. The Cloud is miraculous, actually, compared to the flawed design of the mobile UI, lack of QA, … etc…
“Local Processing” is not a magic pill for SmartThings as a company.
I have just recently migrated from Staples Connect to SmartThings, and I have to disagree on it being rock solid. It’s true that all activities and devices run locally, and everything works when the internet connection is out, but there are serious z-wave issues. In particular, when trying to add or remove devices, I often get an error message that a z-wave process is already running, and it can’t do it now. Additionally, z-wave controls often just don’t work the first time, probably for the same reason.
It also has problems if a z-wave switch is in a different state than it thinks it is. If it thinks a switch is on, and it’s not, then you can’t turn it on, and you won’t know why. I’m still using my Staples Connect as a secondary Z-wave hub to SmartThings, so I can still use my Lutron Pico remotes. Most of the time it works fine, but if a switch is on, and Staples Connect thinks it’s off, it doesn’t matter how many times you press Off (in the app or on a remote), it will do nothing. Not until you tell Staples Connect that the switch is on can you then tell it to turn it off, and vice versa.
Honestly, in the (admittedly limited) time I’ve had SmartThings, it’s been much more reliable than my Staples Connect. I haven’t been through a network outage, though.
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
181
@Ben any update on this? Itching to use my v2 but I would like to start with local processing please.
2 Likes
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
182
@Ben now I’m dying for this feature PLEASE. I can’t stand this flaky platform anymore. The timers are dying left right and center. runIn 15 seconds dies. runIn 60 second dies, runIn 300 second dies. I’m getting fedup.
Please get us off this platform to a hub which can handle a load of a few basic schedules. 90% of my apps are dead thanks for this dying platform times (and I’m also getting inundated with notes from folks using my apps because they’re suddenly stopped working thanks to these dying timers)
