Schedules in new API

Hallo,

I wonder if it is possible to create schedules for seperate devices and actions in new API for example sth like:

turning on lamp every day or checking the temperature of every first monday in month.

Best regards

1 Like

I’m going out on a limb here to guess, since I haven’t worked very much with the new API yet…

I am guessing with the new API, all SmartApp “logic” has to be run on your own servers (or as micro-services / Lambdas).

Which means you need to implement your own scheduling engine and/or use one of dozens out there… Even “cron”, I suppose.

It will be if you create a SmartApp you install. But generally its correct you would want to run your own schedules for many things.

https://smartthings.developer.samsung.com/develop/api-ref/st-api.html#tag/schedules

2 Likes

**_Thanks for the comment, Jeff… :slight_smile: *

This is both cool and confusing; but that’s on me.

As you may have read my comments, I making an assumption that there is a very black & white delineation between “API” and “app logic”. My assumption was that “API” allows querying of devices, as well as subscribing to their Events. I assumed that something like “Scheduling” would be in the latter category … “app logic”.

To quote Jody from the other Topic:

There’s nothing in this definition that implies that the SmartThings Cloud API should include a Scheduler. But there nothing that says it can’t or doesn’t either.


So what would help my understanding of the new API might be some architectural diagrams and/or some paradigm philosophy story.

In my very limited experience, it’s pretty obvious that the API needs to provide access to information about the Location and Devices; but the purpose, scope, and functionality of an “App” is still unclear to me. One purpose is to set the authorization scope for the authenticated clients, right? But what other purpose… To have scope and own State, Subscriptions, and Schedules? Sorta makes sense.

Yet: There clearly is a difference between the “old” concept of a SmartApp and the new concept that I’m still awfully fuzzy on.

And it doesn’t help that the new API documentation simply calls these “Apps” instead of “SmartApps”. :persevere:.

1 Like

The API is intended to allow someone to write an app and do more direct control.

In order for these APPs to be easy to develop one feature is subscriptions and schedules when we fire the event into the 3rd party app you get a short lived token passed in along with the config. So you should be able to create a stateless automation if you want.

So a subset of APIs like scheduling and subscriptions only make sense in the context of apps. The apps include data like where to route these events.

As for why there is a scheduler basically looking at lambda we found without that feature it was hard to write apps.

The APP is there to hold a set of permissions you will ask for note the new API has fine grained access, where to route events we trigger, default name, default description, and what kind of backing it has.

From an end user standpoint Groovy SmartApp vs Lambda vs Endpoint SmartApp should all function mostly the same. I expect that given the differences for the latter types to be able to ask for fewer permissions.

From a developer view Groovy SmartApps today have a lot of implicit functionality and lots of restrictions on how you write code how long it runs and how to build multiple things that need to share functionality. These new ways based on the REST APIs have much more clear contracts and have a versioning system built into the APIs. Ignoring the benefits of owning the deploy process etc all these systems are global, meaning getting this app deployed only once.

The other change we are trying to do in the new way of doing things is be very clear on whats happening so state variables in Groovy SmartApps have a lot of implicit behaviors so instead of making an interaction that hides whats happening we can expose those are direct calls. As a developer works with the API I personally expect them to have a better understand how things are working behind the scenes instead of what has happened in the groovy smartapps.

As for the docs there should be links in the new area somewhere so you can provide feedback. We have these things open as a preview now so we can get more feedback. I linked below the docs on smartapps. If there are specific questions around Apps lets try and figure them out here unless we are getting too far off topic.

https://smartthings.developer.samsung.com/develop/guides/smartapps/basics.html

3 Likes

Love the answer…

This here Topic is entitled “Schedules”, and it looks like the answer is “yes … there are schedules”; so we certainly have reason to spawn a new Topic or move over the the existing more “open” one.

There’s a particular line of questioning there, for example, as to whether or not the new API supports a possible “serverless” infrastructure (pub-sub, or use of PubNub, SSE, or ?). @billv has interfaced with Wink and dozens of other smart products, so he can express the question more clearly than I can.

Perhaps jump over to that Topic and toss in a few cents, unless you’ve got nothing new to add?

1 Like