Cloud Scheduling ~ Modes not firing on time ~ A work around!

[bamarayne (Jason "The Enabler" as deemed so by @Smart)]

So, for the past day this has been bouncing around in my head.

@jody.albritton

What about local (AppEngine) schedules?

These schedules will not be affected. Local schedules do not interact with the cloud and as such will not be affected negatively or positively. Local (AppEngine) scheduled jobs will not show in the IDE, similarly to how it worked in the past.

This is @jody.albritton giving us the update on the new scheduler (which btw seems to be working really great).

Well, this gave me an idea!!! I think I found a way to get the scheduling for our mode changes and everything else off the cloud and to the hub!

This is what I have set up with my mode changes…

I have a rule (trigger) that is set to fire at a scheduled time. The rule does only one thing. It changes the mode. I have also created a momentary button tile that can also trigger the mode change. This is the backup for when the scheduler fails.

As we all know, this scheduling occurs in the cloud. Which we all really know oh so well is about as reliable as a weather man.

So here is my idea…

In Smart Lighting ~ (runs local)
Create a rule that schedules a physical light to come on at the time you want the mode to change. For example, I have my porch lights come on at sunset, which is also the time that my mode changes to evening. (The porch lights switch runs local)

In Rule Machine ~ (not local)
Create a rule like this:

Trigger - porch lights on
Conditions - between 4pm - 8pm (sunset changes)
Rule - Between 4pm - 8pm
Actions for true - set mode to evening

So, according to the statement that @jody.albritton made above, the scheduling of the rule in Smart Lighting along with the local running device should all occur on the local hub and not interact with the cloud at all. Thus, local scheduling of a light turning on. (can we say no more failure and missed modes).

The rule in RM is not dependent upon a schedule time, it is looking for the porch lights to come on between 4pm and 8pm.

While I know this is not a very desired way of doing things, I really feel that this would work.

Has anyone else thought of this… my search skills suck and I didn’t find anything. Oh, and I wish I would have thought of this months ago instead of 2 days after the new scheduler rolls out… ugh!

What are your thoughts? Critical and non-critical? Why will this not work? What am I missing? It seems too easy! @jody.albritton did I understand your comment incorrectly?

[JDRoberts]

The flakiness that started around daylight savings time wasn’t actually due to the scheduler. It’s something independent of that that affected people who are also on the new scheduler. Since at least part of the problem is database corruption you’ve now created multiple points of failure in the cloud where messages might be lost, delayed, or duplicated, so honestly I don’t think it’s going to help right now until the platform stabilizes.

They already rolled out the new scheduler, called ticker, to most people. If that works as expected, by itself it’s going to solve the scheduling problems. It’s not going to solve the data based corruption problems except by lightening the load on the database somewhat.

So it sounds like you’re trying to solve one of the old problems which has already been hopefully solved by the new scheduler while creating more potential points of failure for the still existing old problem (database corruption) for which there is as yet no fix.

In addition, I unfortunately have to mention that local processing also appears to be bonkers for at least some of us.

I have a support request in because my totally local smart lighting automations are issuing 15 or more duplicate requests in one minute. Other people have mentioned they are seeing a slowdown in local processing – – it may be from this message flooding, but who knows.

The following log is from a lighting automation that turns on one light. Only since last week I think it repeats until it times out.

If you want a time based backup for SmartThings operations, including mode changes, a lot of community members are just using IFTTT. Take your same idea, but instead of running the first step off of local ST, get it off of ST altogether and trigger it from Google calendar’s IFTTT channel or something similar. Just a thought.

[bamarayne (Jason "The Enabler" as deemed so by @Smart)]

@JDRoberts

They already rolled out the new scheduler, called ticker, to most people. If that works as expected, by itself it’s going to solve the scheduling problems. It’s not going to solve the data based correction problems except by lightening the load on the database somewhat.

So it sounds like you’re trying to solve one of the old problems which is already been hopefully solved by the new scheduler well creating more potential points of failure for the still existing old problem (database corruption) for which there is as yet no fix

Right, it is a solution for an older (hopefully gone) problem. But, it’s a solution to hold in reserve for the future.

I’ve where people have problems with the local processing which makes absolutely no sense, except for this…

Is the local processing pinging the cloud to verify local processing of each instance? And when the internet is down it assumes a positive answer and processes?

To me that isn’t local processing.

Like I said, I know it was too late, but I still wanted feedback on it. Thanks @JDRoberts

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@bamarayne

Like I said, I know it was too late, but I still wanted feedback on it. Thanks @JDRoberts

Yah… thanks @JDRoberts!

Saved me from having to figure out how to say basically the same thing… but I’ll try anyway.

As @625alex are working on the next generation of SmartTiles, we keep looking for “areas of risk” where stuff could get out of sync and clicks getting lost or delayed etc…

If we look at performance over the past week then we find a different set of problems then over the past month, compared to last Sept, etc., etc… In other words, the platform is not only performing poorly; more significantly it is performing inconsistently and unpredictably.

Sure … there are some functions that we could probably have been more solid than others and taking advantage of them to build workarounds for the less solid areas is, in fact, very innovative and pragmatic thinking; especially on a platform that we can’t control.

But I think we are on the cusp of a bunch of fixes. Honestly, there’s no way that SmartThings has earned our trust that these fixes will “stick” or other major problems won’t arise because or despite of them; but the fact remains that the platform is changing enough that creative workarounds are pretty likely to be obsolete or ineffective due to all the other cogs and gears jiggling about.

Take Pollster, for example. It shouldn’t be required at all. Period. But turns out it is required and helpful for various scenarios. Until it broke because of the scheduler, and then fixed with a workaround (an external kicker), etc…

Myself, I even proposed the concept of a standard for an external scheduling service, but didn’t get very much buy-in. Perhaps because it was too low-level, or because there were easier workarounds for now, and because we knew that ST had to fix their native schedule sooner or later.

[bridaus (Brian)]

My IFTTT backups for sunset/sunrise have never failed (or ST hasn’t). Beauty is, I can’t tell and don’t care. It just works. Always. I highly recommend this backup method.