How about you give us their contact info? We’ll save you the trouble.
Siren isn’t the only reason. I don’t have a Siren, but still had the problems
I truly appreciate the updates and comments from the engineering team.
As many of us have been on this side of an outage, we can all understand the stress that they are under. Our rants / comments are helping us with our frustration however should be held till an after action review takes place and the team asks for our feedback.
This is just my opinion, in a sea of other opinions within this string. To be honest, I am surprised at the openness of the technical team to discuss components of the backend infrastructure as this is hinting to the secret sause or Grandpa’s recipe for moonshine.
To the Smartthings team - You got this!!!
1 Like
Thank you guys for staying on top of this and informing us Hope for a resolve soon.
1 Like
Guys, until this gets resolved remove SHM and reinstall it using Custom rules. I haven’t had one issue since I’ve done that. Just a suggestion.
1 Like
While I have still had issues with responsiveness of SHM, I did find another quirk that repaired the number one symptom I was experiencing.
Symptom: Routines such as “Good Morning” ceased disarming SHM.
I decided to step back, and review as I coach people to do in other technology. When I did, I executed several routines with normal function. I checked notifications after each was run. I noted that only the “Good Morning” did not report an arm/disarm event in SHM.
Bingo, you guessed it! My routine had mysteriously lost the action in the routine to disarm. Once I corrected that, function has been restored even with a sluggish SHM.
1 Like
Or pay a higher price up front. I am more for keeping my monthly fees down. 
4 Likes
I agree, the subscription economy is worse than flat payments up front.
Also, I hope ST is buying their engineers cots and pizza.
5 Likes
Just want to add, that I appreciate the updates and statuses that the Smartthings team is providing. Better than the problem being hidden and denied.
A little disappointed that the platform has stability issues. Probably similar to others, I use it as a security system so it’s a bit disconcerting when there are issues with SHM. Not to mention I wanted to hook up a siren to the system. Due to the instability I’ve disconnected my z-wave door lock too which was one of my main uses for Smartthings.
Hope you guys get things sorted out. Again thanks for the transparency and communication. Not something I run across often.
1 Like
Hey guys, just popping in, nothing major to report, but we will be sharing more details as we know them. We’re here, but working hard in the background to resolve this.
18 Likes
On the positive side, I noticed that I was finally able to delete a room via the Android Mobile App today, that was previously generating an error and not deleting. I was getting an “Access Denied” error when trying to delete it via the IDE.
The way the Zendesk email messages are structured no Ticket # is exposed…I’d suggest changing that to help cross references.
1 Like
Generally I’d read putting risk management far ahead of all other initiatives as “Stop Innovating”.
Should we reset our v2 hub now or wait for the dust to settle and ST to give us the go ahead? All should be working and if not reset the hub.
Thanks,
Joe F
But then they couldnt monetize your data.
2 Likes
Hi Joe,
Welcome to the forum.
There’s no easy way to say this, so I’ll just say it.
Your advice to just reset the hub is absolutely some of the worst advice I’ve read here, unless you meant reboot the hub. (There is a very distinct deference)
It’s hard to tell from the outside but the symptoms and clues in these updates imply a real lack of experienced system architectural and design guidance. When I see teams using a NoSQL solution like Cassandra but then layering on some sort of relational model and then Object-Relational on top of that, that’s a REALLY big red flag. (Why do people keep doing this?? There are real reasons the NoSQL solutions exist)
I’ve always suspected the underlying issues with the platform were data storage tier or data access tier related; that’s the hard thing for teams to do right for scalability, availability and performance. Throwing stateless app servers, load balancers etc at a problem is easy; but you can’t just add more servers to the data storage tier. Especially with ORMs and even more especially with “proprietary” ORM; I can’t count the times that developers get data access layer code wrong. Bad lock contention, lack of data consistency guarantees etc.
The fact that scheduled events/routines have long been failing at conspicuous clock times (on the hour, on the half hour, sunrise, sunset) strongly implies database locking contention. Then we hear that ST is “scaling up” the DB, well you don’t just throw DB servers at a locking contention issue; this is a design flaw that needs to be addressed in the code and schema design.
We also hear of unexpected traffic spikes etc. I’ve seen SO many cases in my career where spikes in worker threads due to locking contention are misattributed to traffic increases. It’s really hard to explain why there was a dramatic increase in ST traffic in a single weekend. (Unless everyone at SXSW decided to jump on the ST platform after that marketing RV experience).
So many bad smells from the platform failures!
8 Likes
I don’t think he’s advising anyone to do anything. He’s asking if ST says the platform disruption is resolved, should he reboot his hub at that point to ensure that it’s all working properly again.
I certainly hope so. I hate to see folks pressing that little red button.
I’d wait until we clear out the current incident. Don’t take any drastic measures.
1 Like