SmartThings Platform Developers Perspective

Nope. I said I think if you want to become a certified developer I would suggest paying a fee. Not that paying to be an “official” developer is unprecedented, it costs 99 USD to become an official apple developer. Microsoft charges for some of it’s developer programs. Learning and coding for yourself should always be free.

1 Like

@garyd9, during a developers call about app submission (I think it was Feb 12) I asked ST how long it would take to certify my custom Neurio device.

Somebody from ST (not Tyler) told me at that point that would take about 1 month given the backlog…

@Tyler or @tslagle13, could someone from ST validate this statement once for all:
can ST community developers submit custom device types, and even some that bring
more functionalities than the stock ones (such as My Ecobee Device)?

I’d like an answer ASAP as I’m currently starting to work on a mega device type that will take several weeks (and months with testing) to complete.

The cloud-to-cloud integration device handlers that I’ve coded so far involves a lot of work because I need first to understand the partners’ data model, and then their custom APIs.

So, I’d appreciate if somebody from ST would say to me: eh, all the work you’ve been doing will never be certified, nor it will take advantage of the Hub V2 platform with its local processing…

That would be a wake up call for me, because for the moment, I’m just dreaming like the others.

Thnx for your support.

1 Like

I think this is an important question but the answers are probably very complicated, hence the reason we have not seen anything concrete in this area.

I alluded to a scenario in my previous post where things could be very untenable.

Imagine looking through the marketplace to find out if a device you own is supported, not only is it supported but there are no less than five versions of support. Which one do you use? If you are an end user and one costs money while another is free, which would you choose? Who do you call when the device does not work as it should?

Looking at it through this lens, it makes sense to only have one official device type. The end users want a simple plug and play experience. I am not sure how that gets reconciled.

The other scenario; there is no official device type but there are users willing to pay to get the device integrated even though the vendor is unwilling to provide that support. This would be a perfect area for some kind of bounty board.

A user or users pledge support to the developer(s) that creates the integration. The developer creates the integration and gets paid. Once the vendor sees that there is enough demand for their product to integrate with ST, the vendor could take the solution and build on it or let it remain a community driven project.

Some of these integrations are non-trivial as others have pointed out. Many weeks or months of development time go into some of these solutions and it’s not at all clear that there is a path to get compensated for this.

Hi @jody.albritton ,

The issue you raised above has already been addressed in many appstores: based on some ratings, end users will make the right decision according to their own criteria…It’s the law of the market (based on supply and demand).

For example, on Google play, I can find many versions of the VLC client app: some of them are free and some of them ask for a fee. Usually, the best ones are the most expensive because they bring more features or they are more robust.

So, I was expecting the same for the ST marketspace.

Another argument in favor of custom device types (or handlers): as I said earlier, I’m currently starting to work on a custom device type for a mature partner with millions of subscribers.

To be conservative, let’s say that only 1% of the total customer base will be interested in a cloud-to-cloud integration with SmartThings, that’s still tens of thousands of potential new ST subscribers!!

So, I strongly believe that community developers like us have already brought many new subscribers to ST and can draw even more as IoT is becoming more mature.

My 2 cents.

1 Like

(I’m not even sure what Neurio is… but…) Was that device ever certified? My reason for asking is that about 8 months ago (Jan of this year) I took ST’s own z-wave garage door opener and modified it so that it’d work with ST’s own “doors and locks” module… and submitted it back to ST. It was a trivial change, but it’s been sitting there completely un-reviewed since then. (As far as I can tell, ST’s own garage door opener never changed either.) So, if they HAVE reviewed device types, that would lead me to a different conclusion than if they’ve just ignored all of them.

[quote=“yvesracine, post:34, topic:21842”]
I’d like an answer ASAP as I’m currently starting to work on a mega device type that will take several weeks (and months with testing) to complete
[/quote]Be careful with that. ST is really good about making promises to developers and never delivering… Personally, I wouldn’t put much stock in any promises made by them anymore; especially if this is a serious effort on your part that you would regret if their promises aren’t fulfilled.

1 Like

Hi Gary,

I don’t want to get into a lot of specifics about the www.neur.io case, but this is a typical concrete case of the potential role of community developers like us and the need for more empowerment…

At the beginning of this year, I was approached by neur.io to develop a device handler for them as they wanted a tight integration with ST and could not find any internal ST resources to do it.

So, at that time, I decided to do it because in any case I wanted such a device in my house (power & energy meters for the whole house and appliances) …

I then worked on the device type and completed my piece of work in May. However, there is still a bug in the Android UI since 1.7 that prevents me to submit the device handler for its certification.

You can imagine my partner’s (neur.io) reaction when they found out that this ST UI issue is still pending since May!!

Not only they could not have internal ST resources to do their integration, but the ST platform itself prevents them to complete the integration.

(See my posts in this thread about the UI issue: Android App (1.7) - #7 by April)

In brief, the ticket (#101078) is still open since May 9th…

So, this case reveals the fact that community developers need some kind of empowerment; otherwise, we’ll always end up being stuck between the limited ST resources (at engineering amongst others) and our own ST customers.

My 2 cents.

3 Likes

Did you only get this out of what I posted?

Fine, a badge, something that opts you in as a developer and gives you the benefits as such. The costs of training need to be absorbed somehow, but that would be up to the developer.

How would a developer program “close” the platform, if anyone can join it and develop?

I am just calling for the immediate separation of users and developers and a renewed focus on the developers to move this open platform forward.

Not all users will be developers.

2 Likes

Speaking as someone who doesn’t write code these days, I would respectfully disagree with the above.

I think the Phillips Hues provide an excellent counterexample. They are designed for plug-and-play. They are sold to mass market consumers.

If you go to the app store, there are many different Hue apps available. It’s up to the developers to explain what differentiates theirs, and what would make it worth buying.

If the developer can’t make a clear case for their app, it won’t sell.

Consumers do not appear to be confused by the fact that there are third-party apps as well as the official app.

Any individual app which seems confusing or redundant just gets ignored.

I would expect the same thing to be true of device handlers. Tell me why I would want yours instead of the official one, and I’ll consider it.

Choice is a good thing. :sunglasses:

2 Likes

Patrick, I’m trying to understand this (and please forgive me if you already answered these questions and I missed it.)

If “certified developers” are given a deeper access, ST would pretty much have to do something to certify them. Otherwise, it would be like ide.smartthings.com access… everyone would have it and the certification would be meaningless and lose it’s purpose.

Or, are you suggesting that it really is opt-in? That ST would give deeper access to just anyone that just clicks a checkbox? If so, why bother with any certification to begin with? Why not just add it to the existing ide as a checkbox? Then again, why waste a checkbox/flag? Just turn it on for anyone accessing the ide…

If it’s NOT as simple as a user “opt-in”, how would ST determine who would be certified? If it requires ST certification, then it very likely would end up being “closed” to anyone who hasn’t been certified. How would someone get certified? Pay for it? Create some kind of extensive certification test? Considering that ST doesn’t even have the resources to do fix bugs, where would they get the resources to conduct certification?

TLDR;
Certified developer:

  • Automatically a beta user for new features
  • Can be assigned to support ticket
  • Gets access to special forum
  • Gets special pricing
  • Gets to talk to internal ST developers
  • Ability to monetize SmartApps & Device Types

Sounds like you want to be an ST staff except that you don’t want to be on their payroll.

2 Likes

Here again Phillips provides a good example. Developers have to sign an NDA. That’s significant from the corporate side.

I’ve mentioned in the past that I personally think developer programs that can give developers advance notice of coming features/platform changes, covered by an NDA, generally benefit everyone. JMHO

Actually, I agree. My quote was in the context of how the platform is currently setup. The Hue bridge and bulbs are a good example. There can and should be hundreds of different SmartApps that interact with the Hue bulbs. Should every one of those also require the end user to have a custom device handler? I think some standardization on the actual device handler/driver would be good. How many different device handlers should exist for a z-wave light switch? If many new SmartApps need to add extensions to the device handler it is exposing a technical limitation with the platform.

The analogy here would be that that different HUE apps in the android play store could require you to flash new bulb firmware to the bridge to make them work. I doubt HUE would ever allow that, instead they provide a very robust API for the developers to interact with and the developers don’t need to think about writing bulb firmware.

1 Like

Not exactly. Just earlier access to platform for the developer and some kind of assurance for SmartThings that the developer is qualified.

Take a look at Microsofts Insider program or Googles Experts program.

https://insider.windows.com/

You can learn to develop on IOS for free but if you want to sell your apps in the app store you have to apply and pay $99.

All of the above have their own developer communities, literature, special pricing, etc.

LOL, no. I want to develop solutions independent of ST. In the spirit of openness.

@garyd9 clearly it wouldn’t be as simple as a check box.

What I am calling for is a series of training sessions, documentation and participation that would opt-in to the developer program. Purely voluntary. But after completion you would be able to support your apps, sell your apps, and maybe just, maybe… Make some money.

Something more formal then just logging into the IDE and have no idea what to do from there.

That’s how I (and probably most others) got started with doing ST dev. In your idea, would this still be an option, or would a person be required to go through the series of training sessions? What about those of us who already are developing stuff?

Also, who would administer the training? Would there be a cost for this training?

Lots of questions…

(I’m only asking because I’m interested in your idea. The first thing I do when I’m interested in something is try to shoot holes in it…)

1 Like

@JDRoberts, that’s exactly what I posted earlier:

I hope that we are all on the same page, as that should be our official position towards ST.

Regards

@garyd9

I think the IDE access would remain the same. However, in order to gain access to things before they are released, there would need to be training, etc.

Think of a certified developer program of sitting on top of the existing tools. Another level, tightly integrated into ST (without having to be hired by them) which allows for support and access to the same tools support and engineers use.

Imagine a group of Certified Developers at ST’s disposal to help integrate 3rd party solutions. I’ve been contacted several times by 3rd parties who want to integrate with ST and all I can do is pass them on to ST. What I hear back is ST doesn’t have the resources or interest to pursue XY or Z.

A group of Certified Developers would allow these folks to help push integration along, or integrate their own solutions.

Training ideally would be virtual, classroom or CBT based. Learning the basics (skipping these if you already know them, like the IDE, our helpdesk software, knowledge base, etc.)…

Even have a projects board somewhere with all the open requests for new integration and a Certified Developer or more than one, could attach themselves to the project and participate.

This is all a dream, has been mine for the last year. The time is now to get this off the ground, or killed. But staying in limbo, especially with the new stuff launching just isn’t an option for me anymore.

We need answers from ST as to how important the community of developers is to ST and not just a pool to pick from and bring them into the fold.

2 Likes

To the best of my knowledge, and having met her, this is or was meant to be Dora Hsu’s responsibility. Hopefully she’ll be featured guest on Dev Conference call and/or publish her vision, unless her mission has been changed – she could be focusing on large vendor partnerships instead of us, for example.

Oh, no! Did you manage to miss signs 3 and 4?

HA is a much more expensive hobby and it’s mostly luxury. People are willing to pay $20+ for a light bulb and $50+ for a switch. Everyone expects to pay bare minimum or nothing at all for apps, but hopefully this mentality would change, at least for HA apps.

This cuts ST out of the picture. Why would they ever support these modes of installation if they never get a cut?

As for encrypted code, 99% of users don’t ever want to see code, encrypted or otherwise. ST ecosystem assumes that every user is a developer, but some are actually not interested in writing apps or ever logging in to the IDE.

I need to build a store first, which is time consuming and redundant (every developer builds their own) and takes away from making the actual apps. And when I’m done building the store, I hope to have something left to sell. The API, ToS or OAuth process could change at any time without notice or someone builds a clone (easier with open source) or ST could come up with a native offering as happened with Smart Home Monitor and SmartAlarm…

The issue is that a product has to come with certain quality and guarantees. When it comes to SmartThings, there is no guarantees.

The approval process is completely arbitrary. Approver may not think twice when hitting the “reject” button. An app may be deemed a duplicate when in fact it’s not or dabbed unpublishable, even though it does not violate any terms of service.

We have been called “important” many times. But I don’t feel important. The developer community is a defining feature of SmartThings and should be treated as such.

This is my observation as well.

Yes!

That thought has crossed my mind too. Let the community developers define use cases, work around the quirks and publish their code so that big name vendors would have easier time integrating their devices and services.

As @yvesracine said, I too need some kind of empowerment. I want to know that what I do is relevant.

3 Likes

Based on the donations I’ve received so far, I have a pretty good idea how much to charge per app, I don’t think that developers should charge less than $2-3 per smartapp if it’s useful and has value.

In fact, I’d personally aim a minium of $5 per smartapp.

I know for a fact that a device handler’s price should be much higher than a smartapp if the device exposes a lot of features combined with a rich smartapp ecosystem.

My 2 cents.

3 Likes