These changes are not firmware dependent. We have just released the beta for the new SmartApp model. Developers may start porting over their apps today and provide feedback. Groovy SmartApps do not have an end of life date and will continue to be supported for some time. Given we are still in the very early days of development I cannot even speculate as to when any switch over might happen.
You cannot do this with a local IP address but the new API’s allow much more control over your account than the old SmartApp Model.
You can rename or update locations
You can rename devices
You can create and modify scenes and behaviors
You can create edit and change modes
A developer could create a web interface that allows you to do most of the configuration/maintenance in a web browser.
I appreciate the reply. So what about Device Handlers, particularly for hub-connected devices?
NB., when I said information on Developer Tools is not available yet, I was referring to tools for developing hub-connected (ZigBee / Z-Wave) device handlers.
I don’t have a timeline but it is a high priority and is under heavy development. The dev portal team is tracking the number of requests to develop hub connected devices and that is one of the drivers towards speed of development.
SmartThings has always been mobile first with the web properties only acting as supplemental to the average user. The web tools we have today are really geared towards developers and there have been many internal pushes to release a “web app”, but it all comes down to demand and resources. If there is enough demand for something, the company would find the resources for it and right now desktop apps are in very low demand.
You will see efforts around making the app tablet friendly and addressing the accessibility issues with the app before you see a dedicated web app or desktop app.
This should be addressed whether or not there’s a current demand for it. You can create demand by finally making the app functional for the many people with different motor and sensory abilities that have a great need for the promises of home automation.
I guess I was not clear in my previous post. I was saying fixing accessibility was higher on the priority list than creating a web app to manage your home. Accessibility is being addressed.
@jody.albritton should we register new Samsung SmartThings developer accounts even if we already have SmartThings IDE accounts? I recall there being a migration in beta for moving accounts from SmartThings to Samsung accounts, but it wasn’t clear to me how that impacts developer accounts…
What I’m hoping for is the ability to…
Update legacy groovy SmartApps on SmartThings IDE (incl. officially published apps)
Create new apps in Samsung SmartThings developer workspace
Access existing locations / devices in Samsung SmartThings developer workspace
If you have a development setup you can just blow it away and create a new account, all new accounts are Samsung accounts. The only way to get your existing locations and setup to a Samsung account is via migration. That should inform whether or not you want to create a Samsung Account.
You will still have access to the classic IDE with a Samsung Account. You can talk to @slagle more about the migration and how that works.
You would still be able to do this after migration.
You need the Samsung Account for these.
There will be some point in the future where we transition to the new developer work space for everything but I don’t even have a guess on that timeline. There is a lot that has to happen behind the scenes to unify everything.
I am not a ‘developer’ in any professional sense of the word, but I enjoy a hobby of building custom esp8266 based home automation sensor devices and integrating them into the smartthings platform for use with WebCore due to the massive amount of customization there.
Will this type of DIY hobbyist coding and customization continue to be possible and supported in the new world being described here?
The new developer workspace is definitely targeting the more advanced developer. The core of the new developer products is the api so in that regard I truly think development will get easier in the long run. While the way smart app development is changing, the desire to allow hobbyists and entry level developers an entry point is still there. Once we have SDKs for the popular languages that will also make development easier. As was announced at SDC and CES we are also merging other development platforms like Artik into SmartThings. It’s going to be a long road but when we get there I think SmartThings will have a great developer story.
@jody.albritton how can users install these developer apps? How can a developer “publish” a webhook app for others to install? Or is that not ready yet?
Cannot really talk about most of that process yet. There is going to be a publication process but we are hoping to make it more automated than it was before for SmartApps. Device Types are still going need to be “certified” by the QA team. We are trying really hard to avoid the mistakes of the past where we made the submission/certification process so complex that simple apps or even updates to apps were taking weeks to make it to the market place.
Hopefully my non-answer at least gives an idea about the direction we are heading.
Will DTH be able to be self published? There are a lot of OOB DTH from ST that don’t really work because no-one invests time (ST or manufacturer) to advance the DTH beyond “it works!” Great examples are the rBoy DTHs. My GoLinear Garage Door opener was completely non-reliable with the ST DTH but since the rBoy DTH I have had zero issues.
Yes. Device type self publication is going to change. If you try the new API it is definitely not as easy as the old model, but we are working on that. For now self publishing in the old IDE will continue to work. Our hope is that folks like Rboy will be able to publish his custom device types for everyone and we can eliminate the need to copy and paste code to get a custom device type. We are still in very early days on all of this. So most of the info that is coming out is targeted more at the developers and not the consumers of custom DTHS.
@rboy’s current code is behind a paywall, which is what enables him to invest so much time in adding all the detailed features. If he “publishes it for everyone” won’t he lose the ability to charge for it?
