External Time Source / Schedule Driver for SmartThings

Wiki Projects & Stories
,
48

One man’s “simple solution” is another’s “complex solution”…

Folks who know me, know that I started the “[Capability Types Suggestions](https://community.smartthings.com/c/developers/new-capability-types)” Category of the Forum (and, I’m somewhat disappointed it is so quiet after some initial interest … :cry:).

Anyhow, even if something doesn’t become an official new Capability, I find it helpful to see if “concept” can be framed as a Capability … and we can even try to agree on the standard.

So…

#capability Schedule Driver: “capability.scheduleDriver”

Description: A Device or Service that provides an alternative, reliable implementation of the Scheduling features of SmartThings. Not sure yet whether it should implement all or just some of the features.

Still very roughly…

###Attributes

  • scheduleName - string
  • scheduleList [ scheduleName : string; scheduleType : type; signalName: string, scheduleDetails : cron string or a single datetime ]
  • signalName - string; Equivalent to the method parameter of runIn(seconds, method, options) (and others).

###Commands

  • schDriver.signalIn(seconds, signalName, [overwrite: true, false])

  • schDriver.signalOnce(dateTime, signalName, [overwrite: true, false])

  • schDriver.signalOnScheduleDaily(time, signalName)

  • schDriver.signalOnScheduleCron(cronExpression, signalName)

  • schDriver.signalEvery5,10,15,30,Minutes(signalName)

  • schDriver.signalEvery1,3,Hours(signalName)

  • schDriver.unscheduleSignal(signalName, [regexp: false, true]) (If regexp is used, this can be quick way to unschedule a whole bunch of stuff like the native unschedule() method… e.g., schDriver.unschedule("${spp.id}-*, regexp: true))

  • any others? Perhaps sunrise/sunset with offset option?

###Usage

  1. SmartApp must request access to a Device Instance with Capability “Schedule Driver”.

  2. In place of any of the “replaced” SmartThings scheduling methods:
    (a) Use a signalName instead of directly referring to the method
    (b) signalName must be unique across all SmartApps that are using the Device Instance, unless the SmartApps are purposefully sharing a scheduled signal. For example, there might as well be two reserved signalNames … “sunrise” and “sunset” which are scheduled by a single SmartApp daily, or are built into the Device Type Handler. For schedules not shared between SmartApps, the developer should always use $app.id as a prefix in the signalName; i.e., myScheduler.signalIn(seconds, "${app.id}-turnOff").
    (c) Call the desired Device.Command equivalent to the SmartThings Schedule method.
    (d) Important: Next you must subscribe to the Specific Device Event that will be sent by the Device per the schedule. This is where signalName gets mapped to the method call.
    i.e., subscribe(device, signalName, method)
    (e) Ummm… That’s it? Earlier thoughts of having the Device Type Handler directly trigger a Virtual Switch or Virtual Momentary seem unnecessary, and do not fit the Capability/Type paradigm (since a Device cannot directly call the Command of another Device).

###Implementation
As with any Capability, the method of implementation does not matter, as long as it provides the standard Attributes, Commands, and Events described above.

  1. The Schedule Driver Device could be implemented via a physical small processor Thing (e.g., Arduino or rPi) using ZigBee or ThingShield to communicate. All that is required of the physical device is a reliable RTC (real time clock), knowledge of the calendar, a cron library, and storage for “many” schedules. – NB: It is possible that the “calendar logic” could all be handled in the DTH and the DTH just convert every scheduled signal request to just “secondsFromNow”. Not sure if this is harder or easier; less or more reliable?

  2. The Schedule Driver Device could be implemented with LAN connected Server or, slightly less reliable and never a candidate for local execution, with a Cloud-Connected Service (and Service Manager).

The Device Type Handler code is the normal abstraction layer between the Device Object and the Device Thing.

  • It could convert Schedules to something simple like “secondsFromNow” and then the physical Thing would return a message when seconds have elapsed and the DTH then issues a sendEvent

  • Especially if served by a Linux server (LAN or Cloud Service), then implementation via a “cron” service or “cron” library seems efficient and almost trivial. The Device Type would just be a “cron-bridge” … or whatever you’d like to call this concept. Messages to the Service would be formatted as either a single datetime strings or a cron string.

  • Calculation of sunrise and sunset could be done, given access to the geo-location, in the DTH, a Service Manager SmartApp, or by the Thing or Service itself. In the latter case, the Commands above should offer scheduling relative (+/- offset) to Sunrise and Sunset.

Well… that’s my draft.
Does it sound crazy? Overdone, underdone, or just-right?

Though we can refine this (or toss it) via discussion, the only way to figure out if this Capability concept is viable is to actually build a Device Type and Thing/Service that implements it … and see if it works!

3 Likes