Capability multiThreading

One capability that would be useful is multiThreading. It would identify special processing needs for a device type.

Its core attribute could be “true” or “false”. There would be other attributes and methods related to this capability.

It could be as simple as
DetachedThreads (true or false)

Or, as complex as this implementaiton:

By tagging a device type with this capability, ST would then be able to better assign resources to it in its cloud-based architecture or even for local processing.


Can you elaborate, please? And give an example real-world existing device(s)?


Hi @tgauchat,

I don’t know if you want the definition of multiThreading per se. If so, please refer to

This capability would be useful for device types which require faster response times when dealing with a lot of events to be processed at once (ex. security panels connected to a lot of sensors).

My 2 cents.

Yup – I know what multithreading is…

But I don’t understand why a SmartApp needs to identify which Devices have this Capability.

Capabilities provide information about what functions the user or application can perform with a Device, and/or what information the user or application can get from the device (e.g., Capability Switch performs on/off and reports the whether a Device is on or off).

Multithreading is an internal way that a Device may process things, but I don’t see any need for the user or application to need to know this … can you explain more?

Or do you want any help understanding the purpose of the Capability feature?


Why do we need to restrict the definition of Capability to “… provide information about what functions the user or application can perform with a Device”…

What not using it in a more broader sense? It may also be a way to tag device types with non-functional requirements that would allow ST to better handle them in special containers for example.

And, I gave many examples in my threads…

Bye for now.

Because that is the sole and only purpose of Capability: To define the standard Interface to a Device, not the implementation (internal workings) of the Device.

Hello @tgauchat, the link you provided is a link to the definition of an interface in Java.

We’re talking about a capability within the ST platform. I think that we should not restrict ourselves to a specific language as a baseline. The java language was implemented way before cloud-based architectures for example.

If a ST capability is really just an interface… Why not just calling it … “an interface”…? I think that by calling “Capability”, it denotes something bigger than just an interface.

My 2 cents.

This probably fits something you want the hub to do, not a capability of the end device. Either priority scheduling or different traffic classes. (There are many ways to do this.)

I could definitely see this coming as part of a future rules engine. Or a scheduler. Some specific implementations would be trickier than others, but certainly some kind of user specified prioritization would likely be popular. (That doesn’t make it technically easy for ST to implement, but it never hurts to ask.)

Personally I’d make this something the homeowner could control through the UI, not just hidden inside custom code.

@JDRoberts, I’d argue that some device types will require special processing needs and they should not be defaulted by the hub only.

The non-functional requirements I identified as capabilities in my earlier threads would be indications (or flags) by the device type to the hub of its special processing needs.

That’s my point of view and I think that the capability type threads that we’re creating now are a way to make the ST platform evolve towards a better platform as a whole.

Let’s have an open discussion and see what ST will say about them.

@yvesracine This is a real confusing capability. Why would a device have this? I’m confused as to why a device would need this?

1 Like

@thrash99er, just read the thread from the beginning…

Hello again,

I see a lot of confusion in this thread and I think that is related to the way we each see the ST platform as a whole.

I’d refer to a previous thread I did on this topic.

In my book, a device type is a device controller (not just an UI). This device controller is instanciated into individual devices in our homes. A device type should be autonomous and self contained.

A device type should not rely on any other smartapps for its day-to-day operations. I know that it’s not the case with the current ST architecture, hence my previous posts on the topic. The current tight coupling required between the service manager (smartapp) and its child devices is not a good engineering practice as it can introduce failure points, especially in a cloud/local processing distributed environment. On top of it, the current architecture does not allow us to use any inherited methods/attributes from the parent which is quite restrictive.

A smartapp should be just an app that uses the device controller for a specific task or within a broader workflow.

So, all the capability theads I’ve posted are related to my view of the ST platform.

A device controller should be able to specify to its hub or its cloud containers what non functional requirements (e.g. multiThreading, localProcessing, highPriorityProcessing, strongAuthentication) it requires to interface with the world around it.

I suggested using Capabilities to do so. Maybe, it should be called something else in the ST development environment, but it does not change the fact that we need those capabilities within the device controller to achieve high performance and reliability.

My 2 cents.

P.S. Please refer to my github:

GitHub - yracine/device-type.myecobee: SmartThings-ecobee integration

for a concrete example of a service manager (My ecobee Init) which does not do much (except instanciating child devices at their creation and polling them from time to time). The custom ecobee device type that I created is really self contained and autonomous from its parent (it does not call its parent to realize its functions). Due to the current cloud-to-cloud limitations, it only refers to its parent for refreshing its access token when needed, but that’s all.

This is an interesting Topics and some worthwhile ideas to discuss. It is something different from Capability which is used to define interfaces in SmartThings.

You’re introducing a new concept and when fleshed out needs to be distinct in the Platform.

Can we please change (edit) the Topic Title and Category, though? This Category is for stuff meant for the current Capability paradigm.

Perhaps @Ben can clarify the purpose of the New Capabilities Category and what the most appropriate Topic is for this here Topic on something that isn’t a “Capability” per the SmartThings definition.


@tgauchat, I’m not sure if I should change the topic right now or wait till the ST people take a stand on these capabilities (for lack of a better word).

Let’s see first what they have to say… And, then, I will change these topics’ title to other suggested categories accordingly.

Hi @tgauchat, as I said earlier, I don’t think that we can restrict capabilities to just plain interfaces.

I have not seen any subscription to interfaces (the way we do within the ST platform) before (in Java or any other languages).

What I have seen however is the concept of a subscription to device handlers (as parts of a device controller)…So, my point is that capabilities are more than just java interfaces.



I personally strongly disagree, but let’s see where the discussion goes.


@tgauchat, BTW @Mike_Maxwell asked the question about capabilities during the developers call tonight and here is the anwer from ST:

Aren’t capabilities pretty light-weight (i.e. interfaces)?

(ST) Tyler Lange
our submission process needs to be better before we can say that with a straight face

So, let’s be patient and I will move these capabilities under the right title after that.

Representing the technically oriented, but without formal s/w training among us, I think the answer to this . . .

. . . is so it can be relative simple and easy for us to understand.

I’m also struggling with the idea that a device can carry some sort of priority or special processing needs. How about thinking in terms special processing needs being a built-in characteristic of a certain capability? Maybe a capability.streamingVideo or a capability.panicButton are hard-coded in the platform with special requirements (priority, processing methods, whatever).

Then, if you need a device to get special requirements, you write/use a device type with the capabilities that carry those special requirements. For example, the same physical device may be a ‘contact sensor’ or a ‘panic button’ depending on what device type you assigned to it. Using the the device-type with capability.panicButton somehow drives some different behavior in the platform.


1 Like

I don’t believe that answer was in response to the question directly above it, but it’s not wrong in this context either. We’re starting with this sub-forum to collect feedback but clearly need to move to a more mature system for managing ideas and submissions.

1 Like

Hi @AaronZON, I understand your point of view. The capabilities that I suggested would be probably used by developers who want to take advantage of all the ST platform can offer in terms of scalability, performance, and reliability. For developers who just want to code a simple smartapp, those capabilities would not be required. Some defaults at the hub/cloud levels would be applied.

I personally believe that having a hybrid architecture (local processing + cloud based architecture) is the best approach for the long term.

The processing needs that will be required for handling hundreds of devices at home and at SMBs later (the Small and Medium Businesses is a big market) justify a cloud-based architecture.

I personally have close to 100 devices at my home, and I have just started my home automation projects.

Bye for now.