That does not scare me. I have run mission critical systems in the cloud. With the proper architecture and design, it isn’t that much of a concern.
For the home user, I am much more concerned about the downtime I see with comcast and the robustness of the physical devices. The reliability of the “cloud” doesn’t really concern me with regard to smartthings.
For me, Comcast has been down more than Amazon has…
I think it would be / would have been useful to have some local control for either a cloud or Internet connectivity issue. I he vent opened the hub up so I can’t speak to the internals but I suspect that there’s not enough capability built in to allow for even limited local control. It doesn’t mater if its a connectivity or data center issue - if your system is completely reliant on being able to speak to a remote back end server, either scenario puts you out of business. I have dual pipes with failover so I don’t really worry about connectivity issues but the last Amazon outage really did wreck havoc on my installed environment. I have a great number of devices on Vera for that reason and about 15 on the ST hub but as luck would have it, my a/c is on ST and was “off” when the Amazon outage rendered the system inoperable. The switch is not easily accessible so it was a real PITA to get to it to turn on the central air. The other issue was that for reasons I can’t fully understand, the outage apparently cut off power to my roof mounted WIFi repeater which is the AP for all my security cameras so I had to climb up on the roof, (and its close to a hundred degree day), cut some wire ties, open a sealed NEMA box and manually turn on the power. When the ST system works, I love it but I still have an issue with being totally dependent on the cloud and connectivity. I have an Almond+ coming at some point which has local control capabilities (or so it is claimed) and Canary and whatever the other “canary clone” are projects I’ve backed which indicate they will have local control as well.
I also supported the almost+ kickstarter. However, I am highly concerned about their API/platform. If they don’t address those concerns, they are just another Vera that can function as a wireless router…
Eh, my internet is solid, and I could always augment it with failover to an aircard. The only times I’ve been down is when SmartThings cloud has gone wonky…and that has been fairly often. There have only been a handful of complete outages, but the latency can sometimes reach over 5 minutes, which I consider an outage.
I rarely agree with Solardave, as he can come across pretty abrasive, but I do think the cloud is causing a lot of issues in this situation. I’m not saying it can’t work, as that’s silly…there are plenty of cloud systems out there that work fantastic with 99% uptime. But, it isn’t working now and I’m not giving them a free pass anymore for being a startup. They are selling their units retail now, they are all growed up and need to offer a better quality of service.
Oh, I am not trying to argue that smartthing’s implementation isn’t an issue. I am just saying, you can’t say “the cloud is the problem”. I would just say that smartthings has issues as mentioned by your latency issues. But I bet when those are occurring, Amazon isn’t experiencing any issues. Either smartthings services are undersized, unoptimized code, and/or poor design. None of those things point to the cloud being unable to support a product like this.
I do also concur with solardave1 that I would like there to be some level of local capability especially with my issues with comcast…
I think we’re moving into a new age in a lot of ways. This isn’t exactly shocking to anyone I know, but I think it’s important to look at things with a long range view in mind.
What I mean is that many things that seemed luxuries or only for specialized individuals are just now common place… even necessities. Heck, you can even get the gov’t to subsidize a cell phone for you if you can’t afford it. Those of us old enough to remember the old rotary phones might question: “When did a cellphone become a necessity?” but they, in many ways, have become that. When did AC or a Microwave or Cable TV move from luxury items to expected things for standard living conditions?
So what does this have to do with ST and the cloud? It wasn’t that long ago when high speed internet access was only for those who were rich or needed it for work. The rest of us used dialup modems. These days I strongly suspect that more people in the US have high speed internet access in the home than don’t. I also suspect that in 10 years high speed internet access will be the expected, perhaps even subsidized by the gov’t if you can’t afford it. It’s moved from a luxury to a (near) necessity.
To this end to have a system that is dependent on a stable, always on, high speed connection isn’t really that far fetched. I think 5, 10 years from now the idea of having cloud based activities won’t surprise or really bother anyone much.
20 years ago the question was: “You have a cellphone!?!?” 10 years ago is was: “Do you have a cellphone yet?” Now it’s: “You don’t have a cellphone?!”
Now we’re asking: “You rely on a cloud based system for that?” In 10 years it’ll be: “You don’t have this cloud based yet?” In 20 it’ll be: “You expect me to host this on my own system?!?”
Now, having said all this, we’re not living in 2033 right now. We’re in 2013 and cloud based systems are still (relatively speaking) young and not 100% reliable. I’m certainly not going to trust any “mission critical” parts of my house hold a cloud based system yet. However, I still think the ST system can be used extensively while still have the ability to have manual control and backup. Everything that I’ve setup (with the exception of two small things) has only enhanced what I could do before. It’s never taken away the manual system.
For example, I can remotely unlock my door… but I still can use my key (and in a keypad) to get in. I can turn on/off my lights… but I still have a manual switch for every thing yet. I can adjust temp with ST, but my thermostat can still operate completely independently of ST if it needs too.
I know this is getting long, so I’ll trying to wrap it up here. In summation:
1. I don’t know that I would trust any home automation (local or cloud based) for any seriously critical things. I would always ensure that I have a manual was to use what I need to use if the system died completely.
- I don’t think cloud based is as far fetched an idea as it seems to some. Furthermore, I see cloud based becoming much more common and in fact the normal in not too distant future.
(If you actually read all that and you’re curious what the two small things are different from before smartthings: First is a spot where I removed a three-way and have two independent switches. On is connected to the light, the other is a “dumby” switch connected to no load. I have them tied together software-wise, but if smartthings dies then the dumby switch doesn’t do anything. The second is an outlet behind my bed that only turns on my phone charger at night. If SmartThings dies I have to charge my phone somewhere else or crawl behind my bed to press the switch to manually turn on the outlet.)
With something with the capability of a RasPi or BeagleBone inside, the hub could have plenty of local horsepower and connectivity, at not a very high cost. Dedicated hubs like those from Digi et al are going to be priced out of the market very soon, by an order of magnitude maybe. Whoever builds a RasPi-like device with expanded environmental operating conditions, a built-in power supply, and some ZWave and direct I/O, could do quite well.
For that matter the solution might be an expansion unit made by SmartThings. You plug your Hub into the expansion unit, and then the expansion unit into your internet. The expo unit “spoofs” your hub into thinking it’s the SmartThings cloud service (or firmware updates on the hub make it first look for the expo unit).
Oh, I am not trying to argue that smartthing’s implementation isn’t an issue. I am just saying, you can’t say “the cloud is the problem”. I would just say that smartthings has issues as mentioned by your latency issues. But I bet when those are occurring, Amazon isn’t experiencing any issues. Either smartthings services are undersized, unoptimized code, and/or poor design. None of those things point to the cloud being unable to support a product like this.I do also concur with solardave1 that I would like there to be some level of local capability especially with my issues with comcast……
@jleonar I guess it kind of boils down to semantics and what you consider the cloud to be. To me the “Cloud” in this instance is everything that isn’t in my home. If something outside my home fails and causes the service not to work, that is a failure of the “Cloud” whether that be due to optimization issues with SmartThings code, or an all out Amazon outage.
I agree that local hosting of some services is really necessary for this kind of thing, as the “Cloud” introduces dozens of points of failure that wouldn’t exist with a locally hosted solution.
If the current SmartHub does not have sufficient processing power to cache basic and/or “essential” functionality (hmmm… at least turn lights on/off, maintain local alarms, etc.), then this is a serious weak link.
WigWag (disclaimer: Kickstarter complete, but far from delivery, of course), has explicitly stated their “Relay Hub” will cache. I think (?) it is Rasberry Pi, actually.
Regardless, SmartThings could sell an add-on logic hub (or “mini in-home SmartCloud”), if they decide to listen to us with this concern.
However, SmartThings refuses to published their Roadmap and Vision and feature changes (pullbacks) are becoming typical (e.g., the silent removal of the Thing Module from the Roadmap).
…CP
I’m surprised given the depth of redundancy that AWS has in place that a single site issue didn’t fail over to an alternate site but I admit I don’t know (but can realistically assume) that their architecture allows for that but is constrained given the need to replicate applications and data in real time for that to work (burst replication).
The root cause of latency issue if I’m not mistaken was ultimately determined to be a throttling issue also within the AWS environment so can’t really blame ST for that one.
Lastly, the tech ST support is some of the best I’ve encountered. I recently had a complex and “bizarre” issue with the hub going offline and then magically being able to open the port to the ST back end. The speed and depth of ST’s trouble shooting was nothing less than world-class. When I say bizarre, I’m not kidding - at one point I sent sniffer logs to ST and they identified that the z-wave error code doesn’t even exist yet there it was in the logs. Had the system not “magically” come back online, I have no doubt, based on the obvious escalation ST undertook, that they would have figured it out. My infrastructure has dual Cisco enterprise level boxes (routers and switches) that auto failover and redundant pipes (ADSL and SatComm) on a load balancer with auto-fail as well and a hardware firewall and they took a thoroughly appropriate “process of elimination” approach both on my end and theirs to try and isolate the issue. I even got a follow up email the next day (after advising them the problem resolved itself somehow and to go ahead and close out the ticket) to check that everything was running OK. I hope they can maintain this level of service as they scale - that’s a common issue as companies grow.
That being said, the system is designed and marketed/promoted to encourage mission critical application within the end user environment. When you start taking “responsibility” for things like security (door locks, powering security cameras, motion sensors, etc.), 3 9’s is a “must have” and outages or latency or buffered commands suddenly streaming en-mass isn’t acceptable. I am fairly sure that there isn’t enough in the hub to allow for local standalone control. I haven’t opened it up but I suspect that its setup to provide connectivity to the app(s) and back to ST and some additional functionality but nowhere near what would be required to run as a full fledged controller. I like the idea of (conceptually) having another (optional of course) device that would detect loss of connectivity and provide some measure of control when the hub can’t connect but I don’t know how practical (technically) that would be to implement. It would most certainly change the price point dramatically.
Since the outages and issues, I setup monitoring of the hub connection and the status of the AWS infrastructure so I can at least get a heads up if something is amiss. I’m certainly cognizant that this is a $100-200 device which is appealing but I’m torn about relying on the system to “manage my world” because of the above issues and limitations. There are allot of downsides to, as an example, Vera 3 (and other standalone controllers) but they will work even if you lose connectivity and they can be configured for redundancy and you can find “pretty” and “functional” alternatives to the MCV UI but they are complex systems and do require a higher degree of technical expertise to gain a high level of functionality. ST, for the most part, is PnP and therein lies the appeal.
I’ll eventually get my Canary and my Piper and my Almond+ (and all the other “next great thing”) I’ve backed and somewhere between all that I’m sure I’ll find a balance between the advantages and shortcomings of all the above. Cloud computing is a nifty buzzword for remote hosting that’s currently in vogue but the same underlying issues that have always affected data center availability/uptime are the same that have been around forever.
I suppose in a perfect world a ST hub with standalone failover that preserves core functionality would mitigate the issues to a degree but as I said, I don’t believe its technically possible in the current form/design. Just adding WiFi to the hub would be a serious “nice to have” especially when enrolling installed devices like locks where you need to be close and stay there long enough for the encryption to sync up (hence the reason Vera has “high power inclusion mode” and supplies a 12vdc power pack so you can carry the controller to the device to be enrolled. It’s a bit of a PITA but it works. My solution was to use a Netgear wifi adaptor ($29 bucks).
Lastly, and I’ve been a critic of this but upon reflection - the lack of communication on future plans are likely a combination of “still trying to figure it out” and “it’s a business confidential issue” both of which are legitimate - I agree that I may have been too critical out of frustration but I think I’m dead on with the above tirade on the noted relevant issues.
I have to agree that the customer support has been very responsive. And let’s not forget that these guys are early in their lifecycle - startup life ain’t easy! However, I do think there is room to improve in developer support (documentation is and has been a major gap and I’m very surprised it hasn’t been addressed yet), and perhaps they might have considered a longer “private beta” period with a limited set of users while the kinks get worked out. I’d also probably have deferred mission critical stuff like door locks and fire safety until phase 2 when the core platform issues were ironed out. But we have the luxury of hindsight. I think it’s reasonable to stay bullish on the potential and at the same time be realistic on what to expect at this stage. Accordingly, ST should probably manage expectations in that same light. Did I ever mention that better developer docs would be helpful? 
The reason I brought up lack of public visibility of the “roadmap and vision” again, is that someone from SmartThings explicitly used this phrase in their communication to me.
In other words, they claim to have a have a roadmap and vision and that they are sticking to it, and that is the reason we are getting some features ahead of others – it is not “just figuring it out” – at least, so SmartThings claims.
But I am unforgiving of ignorance, if that is the reason they are stumbling along instead of following a published road-map… (no insult intended to anyone … I’m saying this from a comfy chair in a hidden location)
To me, these things are obvious:
- The Android UI platform should have been developed in complete synchronicity with iOS. ... and, Android development is not rocket science. The Android platform has been around for many years and there are tens of thousands of qualified programmers available.
- Ditto for a web UI. Heck... even more important and obvious than Android, as it would cover many bases.
- The risks of the SmartCloud are incredibly obvious and I have mentioned them from the very first day that I contributed to the Kickstarter. How to resolve these risks may not be obvious... but SmartThings has had plenty of time to commit to developing a solution and publish the timeline for this ... which they have not.
- These risks include the inability to have Z-Wave devices join the network if they are too far from the hub. Unless I am badly mistaken, Z-Wave (and Zigbee?) is not able to take advantage of mesh range extension until AFTER the join process. Vera solved this problem by providing join functionality in the hub itself with no internet connectivity required. The SmartHub, conversely, doesn't even have WiFi to permit entering join mode if you could move the hub close to your Z-Wave door lock or wall installed outlet or lightswitch.
- The Kickstarter campaign (and the SmartThings ecosystem) explicitly created a "Developer Community", and yet a huge proportion of the development tools and API are undocumented. From a business perspective, this may not be a problem... there are more consumers than developers; but from a "Developer Community Member" perspective, this is not an "open source" project, and thus, half of the product has not been delivered.
- ... and a few more; feel free to list your biggest annoyance that you think is "obvious".
Anyhow… things are improving slowly, and, I agree … Kudo’s to support and the Office Hours, etc… A lot of stuff is being done very well.
Just a few things seem very bleak and are not progressing at all … the Cloud risks included.
@cp - like I said, I bought a wifi adaptor so. Can move to hub to a lock or something installed for inclusion - its a fundamental ip limitation of z-anything that inclusion requires proximity. I have an aeon stick that I use for exclusion.
Yes, you are correct, you can’t optimize the mesh until everything is where you want it t be installed and I’m not even sure that mesh optimization is a generally available fully tested/functional feature yet - I happen to have a build that enables it but I’m not convinced its actually doing a mesh optimization based on (admittedly cursory) review of sniffer logs.
Roadmaps change based on experience and other factors - its just the nature of the beast. Everything looks great on a project plan but things come up when you actually try to build/implement. It would be great if there was more transparency on “plans” but I suspect there’s more going on behind the scenes with partnerships, JV’s, who knows what else.
I’m not defending any e or even taking a position I’m just throwing out observations based on my own experiences.
We’ve all thrown around the term “core functionality” (or similar terms) meaning what we would want to have still operational if the system lost connection with the ST Host. What I guess I’m wondering is what would we consider core functionality? And how should SmartThings handle this?
The reason I’m asking is that this sorta leads into a software design discussion. For example:
I use a modified version of ridiculously automatic Garage Door opener. I would like for this to still operate if the hub loses connection with ST. I want my garage to go down when I leave and open when I come home even if there’s no internet connection. I’ve also considered things like having lights turned on when I come home if it’s after sunset. BUT: If I include that option in this program, my program now REQUIRES an internet connection to operate in order to look up sunset and sunrise times. If I tie this into the Garage Door opener app does this now make the app one that wouldn’t be able to be part of a local control set? Should I separate these are two different apps?
I’d be happy just to manually control devices if connectivity is lost. It was a real PITA to not be able to. I can do without apps and mode changes during an outage as long as I still have control through the app since I can’t physically (easily) get to some of the z-wave or ZigBee switches (like the one that powers some of my Ip cameras or the one that’s in a NEMA box on a mast mounted on my roof next to my wifi repeater).
The term I prefer (and I think the term is used in the WigWag system) is “cached functionality”.
In other words, their “Relay” (hub) will store some significant quantity of the programmed Rules (Apps) locally; that makes for fast execution and resilience. Frankly, I don’t think it takes a ton of processing to do this for “most” typical rules (e.g., motion detection turns on lights, out of range presence tag turns on alarm, …).
As for the Sunrise/Sunset example, this is something that could easily be recoded to use well known lat/long tables that calculate the sunrise/set time. I have a $15 outlet timer that lets you input your timezone, latitude and longitude, and even the start and end dates of daylight savings time, and manages this all in a 2.5" x 2.5" box. It’s a pain to program … has a couple buttons and a big selection dial; but it does the trick.
Sunrise and Sunset can be cached in the hub – or at least remember the values from the previous day, since the variance won’t be much from one day to the next.
Of course, there will be many Apps that require live internet connectivity; yet we are being “manipulated” into believing these are going to be ubiquitous – due to the model of “cloud-to-cloud” communication.
random e.g., For SmartThings to control a Nest Thermostat, they go to the Nest internet web api – instead of talking directly via Wifi to the local device. See the difference?
Yes – there are definitely arguments pro/con for each way… I’m just pointing out that a heck of a LOT can be done locally, if we really demanded that in the ecosystem, even if that requires a more expensive caching / processing hub, and SmartApps that are portable from the cloud to local (or, more directly: A philosophy that all SmartApps should aim to be LOCAL friendly, and only use the Cloud when necessary!). That’s the reverse of what SmartThings promotes.
Sigh… I’ve said this all before.
@cp - any idea when wigwag will start shipping? I’m pretty sure I backed that one but I’m too lazy to log onto KS.
Scratch that, I got un-lazy and checked. Looks like I pledged the $249 developer kit. Since it includes an Aruino shield, I wonder how a ST shield might plug in and be used to integrate them. This could have real potential. I know Canary will have an open API which should be accessible via wifi. There are too many fragmented but excellent products coming to market not to spend some bench time figuring out how to get them all to play nicely together.
Now if only ST had a Jetpack…
@solardave1: I agree 95%
I'd be happy just to manually control devices if connectivity is lost. It was a real PITA to not be able to. I can do without apps and mode changes during an outage as long as I still have control through the app since I can't physically (easily) get to some of the z-wave or ZigBee switches (like the one that powers some of my Ip cameras or the one that's in a NEMA box on a mast mounted on my roof next to my wifi repeater).
Unless I have poorly organized my system such that some routine, yet critical function requires an “App”, I would definitely be mostly happy with just basic on/off/dim controls and sensor readings.
Add on basic scenes / moods, and I get to 97%.
Maybe WigWag will be 98%, if they succeed in this “cache” design.
WigWag receive 910% of their funding goal. That means they are going to be several months behind their estimated delivery dates of November 2013.
Kickstarter is bullshit. Running a $50,000 Project (goal) vs. a $450,000 Project takes an entirely different skill set and timeline. All Projects there should have funding limits. Let these companies earn sales or funding by traditional ways once their “goals” have been reached.
…CP.