Time based events failing?

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.

Thanks! I’ll give it a look

still few issues here. each night for the last two nights one sunset device failed to come on…

Same here…

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.

backend servers overloaded again?

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’m still having schedule problems. My themostat SmartApp which uses schedule() is just not working unless I re-save the SmartApp every day or 2.

Frustrated

1 Like

For about a week I’ve been seeing a noticeable lag on my GE link (zigbee) bulbs.

My setup: ecolink open/close sensor with GE link bulbs. Smart lighting app has the bulbs turn on when the door opens and of when the door closes.

This was running local and there was never a delay. Not local anymore and now a delay.

Most likely the travel time is causing the lag. Not sure why they aren’t local anymore.

My guess, something in the servers are conflicting with the code for cloud/local parameters and causing all of our problems.

1 Like

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.

And well lights off at a specific time went for a toss this morning… Just when we thought things were ok! :frowning:

It’s back for me for my weekday “Have a good day at school” announcement.

Snapshot just taken today, on 11/9/2015

Check this to see how I fixed all of my problems with one Hub reboot (not even power cycle, just pushing the red button on the hub)…

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.

1 Like

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.

2 Likes

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.

1 Like

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. :smile:
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.

But they’ve “fixed” the problem, and put "self healing"measures in place, right?

So why is my “next event” still 4 days ago?

Maybe their “self healing” script is stuck in the past too.