Capability multiThreading

Hello,

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.

http://docs.oracle.com/javase/tutorial/java/concepts/interface.html

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.


Thanks!

@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.

Regards.

OK.

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

ttyl.

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

Mike_Maxwell:
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.
Cheers.

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.

FWIW

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.

Hi @JDRoberts, I don’t know if you were on the developers call yesterday… There was a lot of talk about reliability…There is a lot of devices out there that are not z-wave or zigbee. In fact, I think that a lot of the upcoming devices will be wi-fi or bluetooth or some kind of variation in the near future.

The developers of those devices need to be able to implement them with performance and reliability characteristics built-in, and not rely on their network protocols to do so.

This approach would allow the ST platform to achieve a good user experience from beginning to end…

Thanks for your input.

1 Like

i’m sure you’re right: apple’s HomeKit is going to greatly increase the number of home automation devices with Bluetooth.

However–the most recent Bluetooth standard approved Bluetooth
Mesh. The good news is that means range longer than 50 feet. The bad news is that means it’s no longer point to point, no guaranteed command sequencing.

My personal guess is that a lot of Bluetooth home automation installs will rely on Bluetooth mesh for all the same cost control and network resiliency reasons as zigbee and zwave. So I don’t think Bluetooth will necessarily solve the problem.

As for wifi, three issues there, which is why WeMo doesn’t already own the home automation market.

  1. power consumption is higher (this is why WeMo’s own bulbs use zigbee, not wifi)
  2. each device requires its own IP address
  3. number one complaint about wifi devices in home automation is that the network is not self healing. When a device drops off for any reason, you often have to reinclude it. Look at the complaints people have about WeMo devices needing to be reset every few weeks.

Yes, you can harden the network with a lot more money. But–it’s a lot more money.

So I agree we’re going to see more Bluetooth devices next year. But if they’re Bluetooth mesh, it’s still mesh.

1 Like

@JDRoberts Also, I’d say that some of my z-wave devices (locks and thermostats for example) would also benefit from non functional capabilities… I don’t know why exactly there are so much performance lags, but I think that just relying on the 4 OSI layers (up to transport) for performance improvement is not enough.

I found a potential name for the non functional capabilities that I suggested…

We could call them device type annotations (loosely derived from EJB annotations) if we want to distinguish them from functional capabilities in the device type category…

Like I said in earlier threads, they would give additional information to the hub or to the cloud container(s) for handling a device type in order to ensure high throughput, reliability, security, etc.

Ciao.

1 Like