Those might be two separate issues. Re the first one, see my post above for how I fixed my mode problem. I know it shouldn’t be necessary, but…
On the matter of the false presence sensing, check the “Minimum away time.” I found that values smaller than 2 minutes were unreliable and prone to false alarms.
Slowdowns with the mobile app or the devices responding to a particular event??? I ask this because over the past week my devices (in particular - zigbee) are slow to react to motion and/or open/close sensors. I have had anywhere from 1 to 5 second lag from the time motion is detected/Door is opened to the time the light comes on. This lag is not for all my devices. Ironically, my wemo switches/socket which are NOT connected to ST but are controlled via a httpGet() within a smartapp respond quicker than most of my devices connected directly to ST.
Both, but particularly automated responses with motion and other events. The thing that pisses me off the most about it is these things are supposed to be run LOCAL so they should be faster and more reliable. This whole V2 Hub/App rollout has been a colossal failure IMO. I have even less stability and reliability and functionality after completely rebuilding my network. Everyday I’m having to chase down some bug, figure out why my porch light didn’t come on or why the hall lights have stopped responding or why the garage door only opened half way or why the door didn’t unlock, etc. Every. Day.
I use ST muti’s and GE in one of our closets (and it’s like instant and at times even before the door opens fully). Runs local. ST multi’s on other closets with Crees are a little slower as Crees don’t run local…: but overall not seeing much slowness except for the iOS app which definitely is slower than couple of days back.
Oops! For me it’s only one specific routine which didn’t run this weekend (didn’t notice then) and this morning. I reconfigured it and it looks to be scheduled correctly for tomorrow morning. Guess will wait before pushing the red button as everything else pretty much works.
Yeah, reinitialiazing the routine is the first thing I would do too. In severe cases of poltergeist events like where different sensors start going haywire, I would kill the local processing.
Is it too soon to wonder what ST is doing now that users is fixed and most timed events are firing? Probably sleeping finally. Course I just jinxed it all.
They’re all sitting around watching status.smartthings.com waiting for the next problem to pop up.
Oh, right… That’s hard-coded green.
My basic SmartLighting on-hub automations stopped working today…
Groovy. Should we tell them know it’s break-fix, not fix-break?
As long as my wife has faith, I’m still in.
re: Mr Lucky saying the problem was solved 9 days ago (& cited as the solution in the 1st post of this discussion)
Not for me. My sunset-relative lights-on/lights-off routines still aren’t working reliably. Over the last couple of weeks I’d say they’ve worked no more than half the times they should. The desired actions are supposed to be very simple – turn on some lights at an offset just before sunset, and turn them back off at another offset hours after sunset. This is with the original Hub that relies on cloud more.
That was false optimism on my part.
If you read on, you’ll see where I said it failed again. In fact, it failed again today to switch to Home mode. My “fix” is instant, but seems to only last 2-3 days.
To recap (and this is only for failure to switch mode):
Delete all Routines that involve the failing mode
Remove all reference to the failing mode in configured smartapps
Delete the failing mode
Recreate the mode you just deleted
Add back Routines and smartapp references in the same order you
removed them (not sure if the order actually matters, but it works).
Still haven’t heard back from Support regarding my open ticket on this. Think I’ll ping them after dinner.
Edit: Just updated my ticket online. I would suggest anyone else with lingering issues do the same. It may not do any good, but for sure things will not improve if we do nothing.