Next Developer Call will be on 09/09/2015 - Guest : Alex Hawkinson

[yvesracine]

Hello to all,

Long time ago (it seems years ago now), when there was some discussion about capabilities, I suggested the following ones:

Capability localProcessing

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.

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 nbConcurrentThreads DetachedThreads (true or false) Or, as complex as this implementaiton: http://docs.oracle.com/cd/E19455-01/806-5257/6je9h032l/index.html#attrib-28 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. Regards.

Capability highPriorityProcessing

One capability that would be useful is highPriorityProcessing. It would identify special processing needs for a device type. Its core attribute could be “true” or “false”. Another attribute may be the priority targeted on a given scale (1-5, 5 being the highest priority). This capability would give higher priority processing for device types that deal with a lot of concurrent events or emergency situation (such as smoke detectors and other security related devices). 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. P.S. Of course, there would be strict processing rules to comply to in order to avoid any device type claiming that capability. Regards.

Those non functional capabilities could be called annotations or tags (or something else), but the fact of the matter is that ST developers should be able to better control where and how their device handlers/smartapps should be handled by the ST core engine.

To think that the ST core engine would be “smart enough” to make the right call every time is
a dream…

Developers know better than anybody (or any smart engine) where their code should be optimized at runtime.

I’d like to talk about these non functional capabilities to somebody at ST (so far the discussions about capabilities went nowhere)…

Those are architectural questions that need to be solved one day (or another before it’s too late)…
Especially now with the rate limiting policies that make it harder to do cloud-to-cloud integrations.

So, my 4 main questions for Alex are the following:

1) What is the ST technological roadmap as per the developers perspective?

For example:

a) How SAMI & ARTIK will affect the development platform?
b) Which UI capabilities will be available with the new presentation layer in the coming months?
c) What is the vision for local processing? Can developers use local processing later for their own device handlers and smartapps? If yes, how certification for local processing will work? What are the best practices (if any)?

2) When a “real API” layer will be available?

What I mean by real APIs is some API and security layers that don’t require to explicitly specify each device as a REST endpoint.

3) How do you envision the developers beta program in the short and mid terms?

4) When a real marketspace will be implemented as per the following thread?

SmartThings Platform Developers Perspective

API Web The current system of building one’s own API through SmartApps gives one the ability to create a wide array of solutions, but it does not cover everything. I would like to see access to more of the “Core” API accessible to developers. SmartThings as a platform could grow and innovate much faster if the developer community were enlisted to create solutions to problems like dashboards and control panels. SmartThings the company cannot possibly build the client that is all things to everyone. Allow developers to fill in the gaps. Imagine solutions that are tailored to the elderly with large easily readable buttons, or for the sight impaired with all menus and buttons easily readable by screen reading plugins. Local There is not a local API but it has been much requested. A local API …

I look forward to attending the next developers call!!