Code Submissions and Better Communication

Continuing the discussion from Ubi Connect:

@kris I think you were the one that responded to this submission, if there is another Kris working that, apologies.

I submitted this device type ten months ago and the above was the first communication I received. It was the first device type I created on the platform and I am sure there is lots of room for improvement.


I have no idea what caused this submission to fail. These rejection letters should be teachable moments for us developers. In the future please consider adding information that would allow developers to learn from their mistakes and improve the submission process.

  • I have no idea why it was rejected or what could be fixed to get it approved.
  • I don’t know which version was reviewed. The one from today or the one from 10 months ago.
  • I don’t know if I should even try to fix it as this rejection was blanket and arbitrary.

Just saying re-submit without giving any comments or critiques does not help the developer or the platform.

These submission responses are a great opportunity for developer education.

Use these communications to educate us. Anything is better than nothing. I don’t want to play submission roulette and try and figure out what to fix only to wait another ten months to find out that I did not fix everything or that the device type is never going to be approved at all.


I submitted an app for review and it was rejected because reviewer thought it is too similar to another one. I replied challenging that and I never heard anything back. If they don’t care, why would I care?


And that’s why SmartThings Marketplace won’t ever amount to anything of any significance.

Imagine if Apple or Google rejected Apps on this basis? The stores would be 1/10th the size… Or smaller.

I also absolutely insist that this is equally applicable to Device Type Handlers as well as SmartApps. There are many valid ways to write a Device Type, differing (improving?) on its UI, features, and efficiency of the Handler code; therefore, multiple options should be avaiable for the Customer to select the Device Type Handler of their choosing to override whichever is designated as the “default” at installation time. This need not be confusing, as the selection of an alternate Device Type would be completely optional and not prominently featured – i.e., it is for power-users only, or users directed by the Community Developers that write, offer, and provide support for such custom Device Type Handlers.


Yup, same here, took several emails to actually find out why it was rejected, that was after 6 months?, 2 months ago it was re-submitted…, still in Q…

1 Like

I want to be clear that in no way am I fighting to have the Ubi device approved. To be perfectly frank, everyone that has one is probably already using my device type anyway, and given that it’s a web service it won’t benefit from local execution, anyone that wants to use it needs to jump thru some hoops to get an Ubi API key, but then it works for most. I don’t use the Ubi as a voice control device anymore and my device type is the only thing keeping it out of the sunk costs category of my home automation adventure. This is about communication.

I have had this rejection too, and it would not bother me if they would explain which app it’s too similar to. I certainly don’t want spend time coding something up if there is already a solution for it. The following comments have nothing to do with the Ubi device type, but a smart app that was rejected because it was found to be too similar or duplicated another smartapp.

Given that I did look for a smart app to accomplish what I coded up, both before and after the rejection, I can think of a few possible scenarios for the rejection.

  • SmartApps are too hard to find and the existing descriptions don’t actually explain their full functionality
  • Reviewer really did not evaluate the SmartApp to determine the functionality
  • Reviewer was being polite and used a blanket rejection
  • I did not clearly explain what the SmartApp did.

In any case there were missteps.

When a SmartApp duplicates functionality, is it really too much to ask to point us in the direction of the existing solution? If the reviewers are not properly evaluating the SmartApps, how is that good for the platform or the developer community? If the reviewer is not giving out proper advice on next steps to save the feelings of the submitter, again that is not good for the platform.

If you feel that this is something that we should review again please resubmit!

Here is the issue with this. I already did feel like it was something worth reviewing. People are already using it so there is some demand for it. Without further advice, comments, or criticisms I have no idea in which direction to move. It should not be this way because it signals to me that the reviewer did not feel it was worthy of a real explanation.


I had the same experience with a couple of my submissions as well and came to conclusion that it’s not worth my time.


Yah… the length of @jody.albritton’s post #5, is more than enough indication that SmartThings is making this way too hard.

There are a lots of detailed reasons why the reviewer may reject the submission, and many of them could be easily mistaken. For the reviewer to not give sufficient detail to understand and hopefully resolve the problem, is just lazy. I know they are trying to ramp up approval time, but forcing the “re-submission” process is counter to that goal, obviously.

My theory is that they had such an enormous backlog of submissions that they took an easy way out by mass-rejecting them except for the handpicked few. Hence there’s no detailed explanation why the app or device was rejected and a boilerplate wording: “we still look forward to your innovative ideas and hope you will continue submitting SmartApps for review”

Then where is the enormous onslaught of newly approved apps? A huge backlog should mean that we are getting new SmartApps every week. A cursory glance in the SmartApps section of the Marketplace reveals that most of the User Submitted SmartApps were last approved or updated in June-July 2015. This date is probably a little deceptive as it coincided with the move to github and some are much older. With the trickle of new SmartApps it would seem that the backlog is full of apps that have not met the requirements of publication.

How many other people are just giving up?


I made a submission of a device type and never heard anything from them. I have better things to do than worry about the submission process. So it didn’t take much for me to give up.


There was an “onslaught” of published apps back in June - July (35 apps total), as evidenced in the SmartThings blog. That’s when most of the submissions were rejected to clean up the backlog.

… and

… and

… and

Hey @jodyalbritton, agreed on giving more detail, which was an oversight by me. Unfortunately with lacking resources and time constraints we batched this to quickly clear out some of these submissions. We want you to resubmit if you think it was an oversight.

Honestly we want you to resubmit in general if this is a unique device! Over the course of the next few weeks all DTH submissions will receive a similar email asking them to resubmit because our migration between GitHub repo’s didn’t go as smoothly as possible and the easiest way to migrate these PRs is to just ask for a new submission.

1 Like

@geko We’re working on something that will eliminate that issue going forward.

1 Like

@jodyalbritton @geko We did have a large backlog, which we’re trying to stay on-top of. I would encourage you guys to not give up on submissions. We’re working toward a better model for developers to get their submission through regardless of differences, etc.

We know there are a ton of improvements needed (such as making sure that the developer who created the code is the one submitting and publishing it, etc.) and as this process has just started growing I ask that you bear with us just a little longer. :slight_smile:

1 Like

Which is a perfectly reasonable explanation and should be included if you plan on batch emailing those developers. Asking for re-submission due to github issues is a completely different thing than a rejection letter.

@kris Thank you for responding. I just want to make sure that developers are not getting left behind or let down. Take every chance you get to reach out and help us get a little better when things are not up to standards. I think if someone takes the time to build something for the SmartThings platform and then submits it a genuine response is warranted.


@jodyalbritton Very valid point! Will do this going forward. That being said there were rejections sent that were due to issues, but re-submit and we’ll send more detailed responses.

1 Like