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.
We. Must. Have. Documentation.
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.
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.
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?
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.