Capability localProcessing

Devices & Integrations Capability Type Suggestions
1

One capability that would be useful is local processing (with Hub V2). It would identify local processing needs for a device type.

Its core attribute could be “true” or “false”.
Of course, there would be other attributes and methods related this capability such as :

percentLocal (desired local processing percentage)
emergencyIndicator: indicate if device type’s local processing is required when emergency situation arises (ex. smoke/CO2 alerts,power outage)

This would allow ST to better control these types of devices…

Regards.

2

Not sure what you mean?
Example Devices, please?

3

Example: Thermostats & Security panels would require some local processing capabilities…

4

Not in the Hub – we have plenty of Thermostats that manage their own schedules and setPoints, etc., without any local processing in the current Hub V1.0.

So I still don’t understand the value of marking this as a Capability (especially since you are changing the scope and definition of SmartThings’s “Capability”) as in the other Topic on Multi-Threading.

http://docs.smartthings.com/en/latest/device-type-developers-guide/overview.html

The SmartThings architecture provides a unique abstraction of devices from their distinct capabilities and attributes in a way that allows developers to build applications that are insulated from the specifics of which device they are using. For example, there are lots of wirelessly controllable “switches”. A switch is any device that can be turned On or Off. Switches can come in the form of pluggable outlet overlays, in-wall outlets, in-wall light switches, etc.

When a SmartApp interacts with the virtual representation of a device, it knows that the device supports certain actions based on its capabilities. A device that has the ‘switch’ capability must support both the ‘on’ and ‘off’ actions. In this way, all switches are the same, and it doesn’t matter to the SmartApp what kind of switch is actually involved. This layer of abstraction is key to the successful function and flexibility of the SmartThings platform, and is made possible by a concept called ‘device-type handlers’. Architecturally, device-type handlers are the bridge between generic capabilities and the device or protocol specific interface actually used to communicate with the device.

Anyhow… I’ll defer further discussion pending more input.

5

@tgauchat, yes it’s true that there are plenty of thermostats that don’t rely on local processing capabilities at the moment. However, this would allow them to be more reliable in case of power outages or any networking issues between your home and the cloud.

1 Like
6

Maybe just wishful thinking on my part, but, I would hope that any process that would benefit from running locally will be moved to the hub with V2 and there will be no need to try to control that in the device type via a capability. It seems like it’s in ST’s interest to move as much as possible out of the cloud and onto the hubs as possible.

I’m also with the puppy regarding anxiety around expanding the scope of what a capability is. For us part-time hackers, simplicity and consistency is important.

2 Likes
7

I don’t think this needs to be an explicit capability. I think all smart apps should be designed for local first with a graceful degrade back to the cloud, with the caveat for apps that are purely cloud to cloud where local functions would not make any sense of course. Since we don’t even know what operating system nor how much access we will have to said in hub v2, this is all a bit unknown.

2 Likes
8

Hi @jody.albritton, I will give you an example. I have a ‘groveStreams’ smartapp that just collects data from my sensors, my thermostat and others based on different device handlers and send them every 5 minutes to groveStreams for data correlation and dashboarding. The groveSreams smartapp uses some reportData() and other related methods on my custom ecobee device to do so. These methods could be annoted to run in the cloud only.

I have another smartapp that just exposes some of my devices’ endpoints for remote access via tasker.

These 2 smartapps are not required to run locally. They should run only in the cloud so that later my hub V2 dedicates its raw CPU power & memory for the real-time processing needs of my device types (such as my z-wave locks and switches which are quite slow at times).

What do you think?

Bye for now.

1 Like
9

On the Developer’s Call a few weeks ago (3 calls ago, I think?), we asked if the Hub V2.0 enhancements to the Platform would have ways of doing your request and/or (at least) specifying which SmartApps and Devices or Types should have priority for any limited memory space in the local hub (I consider the Hub V2.0 to be a local “cache” of the SmartCloud, but just a “FIFO” approach to memory management is not optimal.

High priority for local execution likely means Security stuff (to keep home secure from a cable cut) or would it be the most basic functions like light switches (Minimote etc) since these ought to have the lowest latency for best user experience. Then again, presumably “resource intensive” or complex stuff would also be optimally kept local as much as possible.

In other words, the Hub V2.0 team is facing some tough decisions.

The addition of new meta{} tags and or {preference} variables to give local priority “hints” makes a lot of sense. Rather than expanding the purpose of the Capability tag, new tags could have specific names or be called “hints”, “directives”, or “annotations”.

10

I think a priority indication for the smartapp, just as you state above, makes perfect sense. But it’s not a capability of the device. Or even of the device type for the device.

It’s information for the runtime scheduler, about this particular person’s use of this particular smartapp. A different customer might set the priorities differently.

So I would move this into the scheduler UI, probably as part of the future rules engine

But definitely not a capability of the physical device itself, or of its device type.

11

If a particular SmartApp is tagged for local processing (or has a local cache priority) don’t all the Devices it requires also logically ought to be local? If the local tag is for resiliency of certain SmartApps, then that seems mandatory. If it is just for performance reasons, then less essential.

Would there be value in having this also as a Device Instance user input Preference setting? It does risk being complex and cryptic to the average user though.

12

@JDRoberts, these ‘batch’ smartapps (as opposed to the real time ones) very often require certain methods on the device type to run. In my case, the device type has to interact with the cloud to get the report data and it’s quite data intensive.

I’d like to run all these data intensive methods in the cloud. In order to do so, I’d like to give annotations to the hub to run them in the cloud and not locally.

Another example of a device type that should only run in the cloud is the smart weather station tile. I don’t want this device type to locally interfere with my other device types, especially my locks and my switches.

Bye for now.

13

I don’t understand what you mean by the physical devices being optionally local in this context.

First of all, all message traffic in ST is already local unless it’s via a web service.

if by “Device” you mean a device handler, I’m admittedly making the assumption that all device handlers will be run locally, because otherwise the hub has to be connected to the cloud to do anything at all.

If by Device you mean what SmartThings calls a Smart Device Type, I’m still trying to figure out what those are, but in that case, yes, I’d agree that putting a custom SmartApp in a particular priority class should move a related custom device type into a priority class of at least that high. And I also agree someone could hurt themselves with conflicting priorities.

14

Why would you want that? Aside from callbacks the hub can still talk directly to cloud connected services. The callback urls will obviously be hosted in the cloud or handled through a dyn-dns type service via the ST cloud that connects back to the hub. In this scenario the ST servers only have to hold a copy of all device states and the cloud infrastructure becomes less important. @Ben has stated previously that ST would like to offload as much processing to the hub as possible. With the specs they have released so far the hub should be able to handle the needs of even a very large household. I think trying to maintain two separate yet complete infrastructures is unrealistic. Even in the scenario with the cloud connected thermostat the hub could talk directly to the cloud service for polling. All service polling results could then be batched and uploaded to ST at predetermined intervals. This makes the hub less dependent on the cloud infrastructure with one less hop. I think the optimal scenario is that the ST cloud is just copy of my data and an entrance point for talking to my hub when I am away from home.

1 Like
15

The current Hub requires all messages to be sent to the Cloud before a SmartApp can process them; well, of course, since the SmartApp only runs in the Cloud, and the Mobile App (UI) can only attach to the Cloud (there is no LAN Mobile App service provider – I’m not sure if Hub V2.0 adds this feature).

By Device, I generally mean an instance of the Device Class, which I think brings along, is constructed from, or shares an instance of the SmartDevice Type Class assigned to it.

(The naming of these two Classes seems inconsistent; not sure why. Why isn’t it *SmartDevice" instead of just “Device”?)

Regardless, the gist of your conclusion is, indeed, what I was trying to say…

16

@jodyalbritton, we should think beyond our houses and also address the SMB (Small & Medium Businesses) requirements at the same time. That’s why I added a capability (or annotation if you prefer) for multiAccountProcessing as well.

Somebody contacted me earlier in that forum about using 100 ST hubs in different rental units…I know that is a bit far-fetched based on the current ST architecture, but with the hub V2, we should establish the foundation for a brand new hybrid architecture with all the raw processing CPU power and memory it can get.

That’s my point of view and I hope that the ST people are sharing my view.

Bye for now.

17

Even in the 100 rental units example, local first processing would be more resilient. Currently a problem in the cloud would mean that 100 units would stop functioning. Local processing would eliminate nearly all cloud congestion problems. Aside from services that use callbacks I cannot think of any real advantage to processing this stuff entirely in the cloud. The ecobee smartapp running on the hub would talk directly to the ecobee api rather than having the ST cloud in the middle, the hub would then report the state to the cloud for synchronization. If I have one hundred hubs this would actually lower the impact on the cloud infrastructure because I would only have 100 devices talking to ST cloud infrastructure rather than 200 if every location had a cloud connected thermostat.

2 Likes
18

Hypothetically there could some very heavyweight SmartApp which would bog down the limited resources of the local processing Hub. Hopefully in this situation, the portions of the SmartApp which are resource intensive (but not local communication intensive), could be executed as remote methods (i.e., partial offloading to the Cloud).

In the current Platform, we don’t have many ways of accessing sub-routines outside of a SmartApp. One way, however, could be to encapsulate that logic into a Service SmartDevice Type. Then, in this particular hypothetical scenario, we would like to mark that SmartDevice Type as “SmartCloud preferred”.

This has far too many hypotheticals at the moment, though. The distributed processing architecture with the SmartCloud cooperating with the SmartHub V2.0 must be a fascinating evolution; unless it is a common (?) architecture pattern.

19

It would have to be something computationally expensive like detecting motion in multiple streams of video to be considered a heavyweight process. And I have an original galaxy tab 3 doing just that with 8 hd streams, and all of the other stuff that is running on the tablet including android, tasker, a dashboard, etc. If designed properly the hub should be able to handle hundreds of devices cloud connected or not.

For some perspective I have a server that is 1 ghz with 512 megs of ram that performs millions of real time event transactions, some involving complex math, every day. On those specs I have a web server, database server, and a redis server.

1 Like
20

This is not an assumption I would make. There are device handlers which communicate with their (physical) devices via third party cloud services (Ubi and LIFX are two examples; going forward I expect we’ll see lots more (Amazon Echo?, etc.)). Whilst these device handlers could run locally, they rely on a functioning Internet connection and therefore may well be relegated to running in the cloud if local resources are otherwise constrained.

The hub could still run locally those SmartApps which only rely upon locally running device handlers; just because some device handlers still run in the cloud does not mean the hub can’t do anything at all locally.

I see it as a dependency graph:

  • SmartApps depend upon (optionally) service endpoints, Internet services and
    Device Handlers.

  • Device Handlers (optionally) depend upon Internet services and local
    devices.

(I use the term “Internet services” to collectively denote an Internet connection and/or SmartThings cloud and/or 3rd party cloud services, etc.).

The priority for running each item locally is reduced if a dependency is not running locally.

My assumptions here are that local processing capacity is there primarily to:

  1. Decrease latency and therefore improve end-user experience
  2. Reduce the impact of a loss of Internet connectivity
  3. Offload processing from the SmartThings cloud to improve scalability and short-term reliability

I suspect the extent to which this last point can be achieved will be largely determined by the ability to correctly cull the propagation of events from the hub up to the cloud, though this has implications for logging, debugging, analytics, etc. (which could be worked around…). Whilst we focus on the processing requirements of Device Handlers and SmartApps, we often forget about all the background overhead of message queues, databases, etc. which must store and handle all these events before (and after) they get to our code.

Local processing will also reduce the impact of a SmartThings cloud service outage, but I suspect that is a side-benefit (or, at best, interim goal) and not a key design goal. Rather, a key design goal will be to improve the reliability of the SmartThings cloud service (it should be more reliable than a domestic Internet connection). This is eminently doable, it just takes time to mature the architecture. Point 3 (offloading processing) is one way to quickly get some breathing space whilst that maturation occurs (when I say quickly, everything is relative). Significantly culling events will significantly reduce message queue processing, database table and index sizes, etc.

Reducing cloud capacity requirements also reduces the cost of spreading the cloud deployment wider (which is key to improving cloud reliability). Each replicated event (across instances) involves processing, storage and replication traffic costs…

An example workaround to the logging/analytics issue of event culling is the hub could log events locally and then, periodically, perform a bulk upload to the cloud. The events in the bulk upload go directly to the logging database. This non-real-time process is more efficient on the data transfer to the cloud, is more efficient for the database insert, bypasses the expensive real-time event queuing mechanisms, etc. Of course, this can only be done for events which are not subscribed to by anything running in the SmartThings cloud - part of the dependency graph processing / local processing prioritisation problem, etc.

This continues to make all the event information available (albeit some of it some time after the event), but removes the savings to database tables, indexes, etc. Given the enormous volume of events and likely small percentage of users who actually make use of this bulk data, perhaps a better workaround is to not employ the above solution but rather just require people who actually want to store/process specific event data to subscribe to those events from a SmartApp in the cloud. This strikes me as a far more elegant solution (less code, less complication, little to no loss of functionality and capacity savings to boot).

An example workaround for the debugging issue is that, whilst a debugging session is in progress (e.g. Live Logging running), the local event culling mechanism is temporarily disabled (i.e. every event is propagated up to the cloud event queue).

But, I digress…it’s often difficult to restrain oneself when presented with so many rabbit holes…

2 Likes