Agreed. There are an awful lot of posts in this thread that are blindly advocating Hubitat on the sole basis that it’s 100% local. It’s admirable, and even a bit tempting, but it’s also a new and unproven product with absolutely no meaningful stability metrics that can be used as a basis for comparison.
6 Likes
Thanks for confirming, at present here it is very intermittent. Looks like they have some problem at ST affecting the U.K.
Frustrating, but I suppose you get what you pay for.
I had an AlertMe System and it worked reliably for many years, then they were taken over by British Gas and eventually closed down, with the offer of Hive as a replacement.
I got some of their Hive sensors and a hub, but decided that ST was a better system for my needs and it could also use the Hive hardware (I don’t use the Hive hub though).
Being totally dependent on the ST cloud is a problem, and trying to explain to your spouse that we can’t switch the lights on because of downtime is not pleasant. When it works it is fine, and I get praise for being able to remotely switch the house lights on for coming home in the dark, but any downtime and that is quickly forgotten.
I have heard of alternatives, but I imagine that needs another hub, and some are not available in the UK.
I think everyone would like an app that can communicate locally with the hub and operate it locally.
Having no way to control firmware updates, and no way to backup settings is another concern.
1 Like
While I would never claim that anyone is being, ummm… “less than truthful” about this; I find it difficult to believe: i.e., that load suddenly and unpredictably exceeded capacity.
This is exactly the same reason that was specified during the major database hiccups a couple (?) years ago.
On the other hand, to be more generous, there are various reasons that capacity actually could be a sudden issue:
- A sudden surge in sales due to a promotion or new product (e.g., Hub V2’s release, ADT Hub, and … recently… SmartThings “Connect” App announcement and migration).
- A sudden change in a portion of platform architecture (e.g., switching authentication services over from SmartThings’s own to Samsung’s?).
- A small change that introduced a bug with major unanticipated side-effects.
- An intentional denial of service attack by an adverse player (or unintentional by a large partner such as IFTTT or Amazon or Samsung).
- or … Unexpectedly hitting the “exponential knee” in the organic utilization curve.
6 Likes
Yes, it was. Let me also say that in my experience, we had people who’s responsibility it was to watch their parts of the system for connectivity, capacity, corruption and throughput issues. And, those people were in addition to the automated ‘watchdogs’ we’d employed. It’s really kind of unacceptable to be surprised by capacity issues - especially considering that it’s occurred before!
Still… (see above).
5 Likes
Most of your response is garbage, especially the part above. The hub is in fact mine as I paid for it. The only way I would accept that it is Samsung’s box is if they paid ME to use it.
Agreed!
And after the last major episode (distributed database inconsistency due to insufficient server quorum issue) we were explicitly assured by SmartThings that they were taking steps to avoid recurrence.
And yet folks here continue to beg SmartThings to give us the same explanation and well-intentioned (but impossible to guarantee) assurances again and again.
Of course SmartThings continously intends to make the platform more reliable. They’re not ignoring the problems or intentionally making it worse. But there’s no value for us or for them to make a promise that is dependent on many, many factors outside their control. (Like the 100% sincere promise of a Hub migration tool… NB: I am not saying “sincere” with any sarcasm or irony. It was a completely sincere intention.).
I’m grateful SmartThings has stopped making promises… Oh wait. They actually haven’t. I’m actually rather worried about some recent high profile promises. No use worrying, I guess: But I happen to be a part of a business that would love clarity — yet none will ever exist. 
2 Likes
My app has been logging me out all day - is this related to the outage by any chance? Can’t figure it out.
I’m sorry to hear that you feel that way. Perhaps I was unclear. Yes, you own your ST hub, as do the rest of us.
But when you bought it, you agreed that Samsung could run their cloud service, on which the hub depends to serve as anything other than a paperweight, in whatever way they want.
To complain about that afterwards, or to insist that Samsung let you operate the box you purchased how you see fit, is just a waste of time.
2 Likes
Everyone keeps harping local local etc. You do realize that a good portion of the devices now do run local on the hub. Out of 138 devices in one of my locations 82 are running local. Of course most smart apps do not, and anything scheduled does not as there is currently no scheduler in the hub firmware. That would be nice to add cron or some other scheduler to the next firmware release. In my opinion a lot of the back end load could be alleviated if this was done.
1 Like
Same here. I had to log in on 13th evening after the outage and I had to do it again yesterday evening 14th.
I might reach out support today
That’s the ST community power man! Solved as soon as you posted 
1 Like
This is not quite true. Lighting Automation rules that trigger at a specific time, or with regards to sunrise/sunset should run locally as well. Routines however, still run in the cloud.
2 Likes
As that might not be entirely true, having every single device in SmartThings be 100% local serves very little in the way that the only automation mechanism throughout SmartThings to be able to have local automation rules processed is through Smart Lighting. This is only a percentage of all the devices people own in their SmartThings environment.
Are there any plans (I know you cannot tell us, but I will ask the question anyway) to allow for all Automations in the NEW SmartThings App (equivalent of Smart Lighting, Routines, Scenes) to execute locally if all devices in that Automation are Local devices, not just bulbs, switches and motion sensors?
1 Like
Yeah, lighting automation being the only real way to have automations locally is very limiting. As just an engineer, I’m not going to talk about plans (and even if I did, I have limited influence on them). However, I will say that it is a known shortcoming, and it has been/is being discussed. In addition, we are trying to make that path forward easier where we can. For instance, local execution of virtual devices (Virtual Switch, and Virtual Dimmer Switch added as of 0.21.X) are of somewhat limited use now, but will greatly increase in usefulness if/when more local automation becomes available. If nothing else, I want to expand MY ability to have my house running locally.
10 Likes
Fundamentally, the only thing that should rely on the cloud is the ability to check and control status remotely. Everything else should be local. If the cloud goes down I should still be able to see status and control my devices from the app if I’m on the same WiFi as the hub and devices. Of course I understand Alexa won’t work as the echo connection is through the cloud. But it’s really annoying, and unnecessary, that when the cloud goes down THE ONLY way I can control my devices is through the physical switches. Some of my plugs are plugged into outlets behind furniture that extremely awkward to reach physically (think under the middle of a king-sized bed), so when the cloud goes down I basically loose those lights. Not acceptable.
Gonna ask a question that you may not be able to answer (and may have been asked before, the thread is kinda long at this point), but I’m curious. I had several webcore pistons that just handle basic lighting and such that still worked during the outage. That’s the first time that’s ever happened. Is there a reason that they worked this time? Usually, if I can’t get into the app, nothing but local stuff works. This everything was down except that. I just found that odd. Wondered if that was intentional or just one of those random things that kept working for no reason other than blind luck.
I’m not sure what you are expecting. We have consistently expanded local execution capabilities in each of the past 4 firmware releases. I understand that it would be better for everyone if everything ran locally, but since you bought the product we have only increased the functionality, it’s not like we have removed functionality that was there when you purchased our hub. All I can say is we are improving with regards to local execution and we hope to continue.
There is, but my understanding of it is limited and so I’m not going to speak to it. I’m an embedded engineer and I work on the hub firmware, so my understanding of the cloud infrastructure is not perfect.
9 Likes
Even though the status page says everything is resolved, the app is still running slow as a dog for me and is unable to tell me about the status of my ADT hub. Not exactly reassuring as far as security goes…
1 Like
Maybe this is bad on me for not understanding it better before buying the system, but detailed information like this is not readily available. It seems reasonable to assume that when you are local, you can control local devices regardless of the status of the cloud. This should be the default, not a “feature” that may get added in some day. Not trying to beat you guys up here, just surprised at this limitation.
That’s fair, and a valid criticism. The specifics of this stuff is available (sort of), but you have to do some digging around on these forums. And I DO want everything to run locally, it can just be frustrating as a developer to be working on improving something and to still get nothing but complaints about it. I mostly just chimed in on this thread because I wanted to correct some misinformation about what scheduling functionality runs on the hub.
11 Likes