no clue about Hue, but you know there was an outage yesterday, right?
Shit. Uhh. No?
If there is a ST outage, it will impact local performance? Shouldn’t the hub have a local repo of devices and routines? (maybe ignroant newb question…)
As @prjct92eh2 mentioned, there was an outage yesterday that affected a lot of people, so you may have been hit by that.
As far as reliability and things changing which used to work, there’s no question that that’s an ongoing issue with SmartThings. The company is aware of it, they are working on improving it, but they aren’t there yet.
In my own case, over the last year I have moved all of my critical automations to HomeKit, because as someone who is quadriparetic, reliability is my top requirement now. Even if the glitches are “minor” and just require popping a battery or opening the app and resaving it, I have to pay someone else to do it, so I’m very aware of the frequency.
I was still using SmartThings for convenience notifications, like being notified if the guestroom window was open when rain is expected, but about two months ago they made some changes to the mobile app which make it no longer navigable by voiceover. I’ve been told are looking into fixing it, but that was a classic case of “worked fine on Monday, totally broken on Tuesday.”
Every system has pros and cons. SmartThings is a very powerful, very flexible low-cost home automation system with a great vision and an excellent community. But if reliability is your top priority, it’s probably not going to be the best match for you right now.
local repo of devices and routines
Yeah… local processing is nowhere near where it should be. Even my devices (of which 40% are locally executed) didn’t work during the outage because the mobile app is completely dependant on the cloud. So, while it can be said that local processing works, it STILL has a requirement on the cloud.
As @JDRoberts said, moving to a platform that does support 100% local execution (such as HomeKit or Vera) for critical devices makes sense.
Perhaps ST will improve reliability sometime soon, but until then, it’s the nature of the beast.
Short answer: No.
Longer answer: Smartthings is primarily a cloud-based system. Hardly anything runs locally. Routines don’t. Webcore doesn’t. No custom code does. The only things which don’t require an active connection to the SmartThings cloud account is some stuff in the official smart lighting feature and a little bit of stuff in the official smart home monitor feature. And that’s it. Your phone app will not work if the cloud account is not available even if you’re on the same LAN as your hub. You won’t be able to arm/disarm smart home Monitor if the cloud account is not available.
On top of that, The company can and does push out firmware updates from time to time which you can neither delay nor refuse which can change even local operation. Sometimes we get A few days advance notice of these, but not always.
There are some mostly local home automation systems which are generally more reliable, but they may have many fewer features and integrations. So again, each person has to choose for themselves what the best match will be for their household.
From what I read, problem could be SmartThings or Hue. Have you looked at the Phillips Hue blog?
Within this forum, have you looked at:
Thanks, but I am familiar with my own threads
The solution…for me…was the newer Hue hub.
Yeah, I read through that thread a few weeks back. I implemented the newer device handler, but still eventually as mentioned, it’s disconnected and just flashes red when pushed. I’ll re-read that thread to see if there is anything new in there.
The fact remains: It worked perfectly for nearly 6 months and then turned to crap in June. Since I haven’t updated the device, device handler, and don’t have a Hue bridge, I can only assume ST’s handling of Zigbee is the issue, and some change croaked my setup.
After re-adding the outlet and putting it back in as a device in webCoRE, My garage light issue is resolved.
Still haven’t dived in to fix the Philips dimmer pairing issue because I don’t remember what bit of wizardry was required to make it work again.
My points are still valid:
ST platform changes have introduced new bugs that have led to instability and lack of reliability. Please stop doing this, or at least increase technical presence so that bugs are caught and fixed quicker.
What device handler are you using for the Hue dimmer?
I ask because technically the hue dimmer switch is a ZLL device, not a ZHA device, So smartthings doesn’t guarantee it will work, and we might have to let them off the hook for that one. Neither Phillips nor smartthings say it will work with the SmartThings hub. There are some experimental device type handlerS that people have been trying with it, but it’s not the same thing as if, say, a ZHA pocket socket stopped working.
I do use the dimmer switches at my house, but I use them as a parallel means of control, I don’t try to get SmartThings to recognize them.
It doesn’t change the basic issue of instability , and trust me, I know that as well as anyone, but sometimes SmartThings is not at fault.
Thanks for responding. the handler is called Hue Switch, and I believe it treats is like it’s a ZHA. Fair enough to note that it has no guaranteed compatibility, but there was a pushed change which broke the functionality, and that’s my core point and frustration.
Happy to note that the light issue I was having appears to be due to remote conditions, so the larger amount of trepidation is gone, and it’s more pointed to this ZHA/ZLL drama.
I don’t think it’s going to happen anytime soon, but I would really like to see more details published on the firmware updates, a list of the specific stock device type handlers that are changed and a list of the coordinator/controller changes as well.
None of that should be proprietary since you can view the handlers and groovy anyway and since the hub itself is a third-party certified device and we’re just talking about meeting the published standards.
But like I said, I don’t think it’s going to happen. But I think it would definitely help reduce some of the frustrations when changes occur.
ST has given users in the community lots of access to things. I just wish they’d push closer to true open source.
I don’t expect them to be open source. There are other options which are open source if that’s what you’re interested in. But I do expect that as a mass market consumer product they reach a MFOP (maintenance free operating period) Of at least six months, and preferably 12. To me, that’s what a mainstream brand label should imply, even on relatively inexpensive products.
Though I work for probably the largest open-source vendor on the planet, my goal was actually primarily stability and features, combined with reliability and security. That there was some community development here was an awesome addition. I just wish that the next 6 months of service could be like the first 6 months…
I hope we can get more stability soon.
Something reached a tipping point w/r/t stability. I’ve also experience some “mysterious things” for which there is no explanation given, so understand your frustration.
Kind of reminds me of the Whack-a-Mole game in an arcade sometimes
Whenever things in my setup fail to work, I take a deep breath, drink a beer or 2 and wait at least 2 hours before I even think about addressing it. I’ve chased way too many ghost! First step for me is to go into the SmartApp and then to the Device and click on Recent Events…
As much as I love ST, the reliability is just not up to what it should be.
Saying all that, I had a pretty good run considering I have over 200 devices.
Wow! I guess so!
Sometimes two beers & wait until the next day fixes lots of things
Certainly very good and learned advice. I will be mindful of that in the future.
It can also be helpful to check the official status page ( although be aware that not all problems end up being reported there).
As well as the first bug report page in the community – created wiki: