Two days later and I'm switching to SmartThings

Why Hubitat Elevation
1

I'm an experienced developer, I've been writing programs since I was a little kid. I've written complex Android and iOS apps. I code for fun and for profit. I love the idea of automating my home to make it more comfortable and to save me time. I like to keep my data close and having an offline option where I can set up an intranet and write my own rules seemed like a great solution.
My ST hub arrives today and I'm returning the Hubitat.
Let me tell you why.

Documentation
We. Must. Have. Documentation.
Must.
Even in the days of yore when I was writing scripts to make custom levels in Doom II I had a print out of the API calls that a friend gave to me. It listed all the commands the system could accept and it was 30+ pages of 8pt font. Here's the Hubitat developer documentation:sparse.
The language has no dictionary.
Ah yes: look at the ST docs. It's the same basic language (Groovy? WHY?!). But some of the API is different from that system, and there is no comprehensive list of what those differences are, so if an error is thrown I have to search through these forums or post a question. That makes development for Hubitat NOT FUN. Imagine how someone with no experience at all would look at it.

App ecosystem
I could forgive the lack of documentation if there were a host of example apps demonstrating best-practices presented in an organized fashion. This does not exist. Individuals post their own links to comment-free code using cobbled together anti-patterns (who can blame them?) in the forums and native apps and drivers are closed-source. This is an educational dead-end, or maybe a bridge-out. Sweet.

IDE
The development environment for a language can make it or break it. (Xcode, I'm looking at you you giant sack of garbage) There are some really great IDEs out there (high five, VSC) and Hubitat development is done with... the Hubitat app editor. Ok, I see the value of running in production environments (risks notwithstanding), but if you are at all serious about doing quality work, a vanilla text editor and log statements will not suffice. Code completion, debugging, GIT integration, function descriptions, integrated documentation.. sounds nice, no?

Forum
This forum is great, it's the source of Information for Hubitat, but it's the source of Information for Hubitat. It's active, has all the bells and whistles (badges! acheivements!) and I bet there was a lot of time spent putting it together, and a lot more time moderating, updating, and improving it. Unfortunately a forum is a really bad way to organize development questions and code 'releases'. I just tried to find a post I read before where a Hubitat employee said they used the Hubitat editor for their in-house development. Couldn't find it. I expect that there is a lot of duplication and meta-posting because a forum is meant for conversation, not for archiving data.

So after taking stock of what's going on here, I'm going to bounce. I'd rather give my data to big brother and buy an app that someone else has created than suffer through this, and I'm the target customer for Hubitat.

I expect that I'll check back in after I get fed up with ST, here's what can keep me around next time.

DOCUMENTATION: A COMPREHENSIVE LIST of API commands is a MUST. Android does a great job of this. An introduction to development for beginners SPECIFIC TO THIS UNIQUE SYSTEM would be great (architecture overviews, best practices, drivers vs apps, child apps vs parent apps, views, persistence methods, ...). A basic groovy introduction and a list of the quirks that are SPECIFIC TO THIS UNIQUE SYSTEM would save a lot of time. Code examples of each API call would be great, but a few samples that cover the most common ones (native apps?) would be very helpful.

APP ECOSYSTEM: Some centralized way to find what others have done would go a long way to improving usability. NPM is the paragon, but there are many simpler examples out there.

IDE: I recently started using Visual Studio Code and it's great. It can be extended to any language/system, there is already a Groovy language mode, and the Hubitat API documentation (if it existed) could be stacked on top of it for code completion and other niceties.

FORUM: Let me save you some time. Moderate conversations, not questions. That problem has already been solved, better and more completely. Keep the forums around for the circle-jerk and more in-depth discussions, leave development questions and code releases out of it.

I'll be watching, but I expect that if someone comes up with a system similar to Hubitat that speaks ES6 it will swallow the home automation ecosystem whole.

3 Likes
2

For being a developer why are you even looking at ST or HE? Seems Hass.io would be a better fit for yourself.

5 Likes
3

Apologies if I come across as overly sarcastic, but you've used Hubitat for 3 days and in that time have already determined that you're Hubitat's target market?

Documentation: I don't think anyone here would disagree with you on this point. In fairness to the Hubitat team, it's improving, although slowly. They've indicated their focus is a rapid expansion on hub capabilities for now, catching up documentation along the way.

Also, SmartThings has decent documentation, but you'll find that it's also incomplete. The Groovy API is deprecated and will be going away someday. That documentation never gets updated. The new API documentation is still lacking too.

App ecosystem. Hate you tell you this, SmartThings has the EXACT same app EcoSystem as Hubitat. You want to find a community written app for ST? You'll be searching the forum looking for it just as you do here. Examples of best practices? Better keep your search skills honed.

I, along with others here will certainly agree with your point about Hubitat not sharing the source of their drivers. But that's a double-edged sword, and I do see their point.. Their drivers (some) are one of their competitive advantages over SmartThings. If they open-sourced all of their code, someone, including ST, could port those features over to that platform. I see that argument both-ways.

IDE. If you're going to count this against Hubitat, you need to count it as a strike against SmartThings. They both use pretty much the same type of web-based IDE.

Forum. You do know that SmartThings also uses Discourse as their forum engine, right? And it's way more fragmented than this forum, with a ton more categories and tags. At least here the staff responds. SmartThings has always maintained that their forum is not for support purposes so most of the responses you get are from other members. Staff seldom respond, except in the beta threads.

If those are your concerns, I'm afraid you're setting yourself up for even more disappointment with SmartThings. Most of us here moved away FROM SmartThings. You'll soon see why..

5 Likes
4

This article sent me on my way. I figured a higher level language would be faster and easier than a lower one....

5

If you think ST is actually "Developer Friendly", you've got another thing coming! :wink: ST used to engage with developers regularly. They cut off all formal contact about 2 years ago.

Try finding their documentation for hub connected devices using the new SmartThings platform. (Not the Classic SmartThings platform.) I'll save you the hassle - it does not exist whatsoever!

SmartThings development environment? Same as Hubitat. You're not going to be impressed.

Documentation - sure it could be better, and Hubitat would love to have some help in improving it. It took SmartThings years to develop their documentation, and it still isn't kept up to date with all of the changes in their platform. Again, be prepared to be disappointed.

2 Likes
6

I thought I was the target customer. I drive a boat for a living, haven't coded since I had a TI99/4a in the early 80's, but have a home that runs itself.

9 Likes
7

I don't expect to do development for ST, I expect to buy an app that has been made already.

8

Oh wow...are you in for a VERY rude awakening.

I was a ST user for 2 years and hated it the whole time. Also, I agree with every single one of your points (to some degree). But I'm still never going back to ST. I'm willing to bet you won't find the grass any greener on the other side of the fence.

3 Likes
9

I don't expect to do development for ST, I expect to buy an app that has been made already.

I see you agree with me in general but say "ST is also bad".

10

You will NOT find this.

2 Likes
11

Internet high five.

12

I already have

13

No offense to Tom’s articles but they are superficial these days and biased to the new breed of home control (Alexa, Google,Etc) verses true home automation. The giants have blurred the line so much that ppl believe home automation is done by telling a device to do something. At least Amazon is realizing the potential of home automation but as with all these solutions they are cloud focused which sucks. HE and Hass.io are the only non-cloud reliant platforms that are being enthusiastically developed by community developers. For a 1yo solution I believe HE is incredible and growing very fast. And as others have stated to staff are excellent about having the community involved and they help!

8 Likes
14

I think some of the OPs points are absurd to the point of being wrong, not just opinions. But whatever.

I'll just say "good luck". If ST works for you, and your use cases, that's great! You certainly don't need to defend which platform you chose to use.

6 Likes
15

@bptworld, stop typing and get some rest. I'd love to hear your opinion but...wait..is that your wife coming in to your room. Put away the keyboard sir.

7 Likes
16

I did SmartThings for 3 years.. I had enough.

In many ways ST isn't much different.. Still a Groovy platform.. Scattered and incomplete documentation.. Fragmented mobile apps (there are 2) with inconsistent functionality across them and a sucky-■■■ cloud architecture... Oh wait, that's unique to SmartThings. :slight_smile:

2 Likes
17

This looks promising combined with a RPi running Node.js and this library

18

I haven't coded since COBOL. With the few examples, ST old docs and utilizing Google, I now have over 20 apps available. Groovy is SIMPLE.

I'm typing s l o w ly. :stuck_out_tongue_winking_eye:

9 Likes
19

I would add OpenHab and HomeSeer to that list.

[EDIT] Almost forgot about UDI ISY lots of nodeserver activity there as well...

1 Like
20

Like I said, I'll check back in. I'm just trying to be informative and helpful, you all can take it how you like.