Being able to write specific code and do what you want it to do aren't always the same thing. I'm not trying to be argumentative here, although it may read that way... Particularly with someone downplaying their Groovy credentials, which I would also put myself in the same camp. I'm sure there would be other mechanisms to achieve an SSL connection...?
Hubitat's Groovy implementation is more of a protected sandbox for users to write their own code in. Hubitat chooses what classes are allowed.
3 Likes
Awesome, thank you for the response!
That makes sense and is obviously the right decision. I'll be looking forward to the dev doc improvements whenever it makes sense for y'all to get to them!
2 Likes
I'm not sure they want to, or care to, compete with apple st all. Dunno.
I'm not against them adding capability. But when there are very little resources I think they need to focus on short term payouts that can be used now, not maybe used later.
But it isn't like it is up for vote. Lol.
3 Likes
I guess you could create a line of HE products with the original hub at the center (or a master RM controller unit)- One could have threads support and another whatever the current popular thing is, WiFi maybe, all connected and interacting via HubMesh and/or Maker API. Kind of like what some of us already do now with NR, HB & MQTT etc but as officially integrated products.
Of course then you've just made your dev & biz environment that much more complex so not really holding my breath on that... just fun to think about.
1 Like
You mean like many of the setups users already have...? 
2 Likes
Love this! On that note though, I do think non-R&D considers 'roadmap' to also include or be a part of a higher-level "Vision" and "Direction".
I LOVE roadmap not being a thing, as the best roadmaps are the ones that are fluid and always in the pursuit of the right Product-Market fit.
Would be super curious if there is any direction/vision/long-term outcomes/goals or KPIs you would be willing to share about Hubitat. I also understand if not!
Thanks for everything you do!!
3 Likes
I also like you guys not having a "road map". The best thing I've noticed is yours and other employees devotion to be part of the community you created. You all seem to look at what people have to say and actually consider those things said and then come up with, "I like this. I'll run it by the other guys for their input" or "I can do better than that" or "F that noise". The fact that your team is cohesive in their individual thoughts shows a type of ability to grow as a group and as a company. You're also very good at explaining why or why not something will work now or in the future without ambiguity. I honestly have to say the overall communication is 40% of why I evangelize this product to people. Is it perfect? No. Will it ever be perfect? Nothing is. Is it a damned good product worthy of our support? Fark yeah...
3 Likes
Yes - Simple Automation Rules, Basic Rules, and the ability to export/import rules for Rule Machine are all major innovations for the platform that happened in the blink of an eye.
That sort of flexibility would not happen if the team stuck rigidly to a roadmap.
With that being said, I do like the idea of an App Store for developers. For that to be successful, developers should have some idea of what value-added services they can "sell" that are unlikely to be immediately provided by Hubitat Inc.
I want to make the case that you can have both smaller more reactive enhancements developed alongside more strategic, longer-term features, and I feel that is generally the case. But given Bruce's comments about how HE are "not into roadmaps", it's hard for me to make that case in this instance, not that I feel this is an argument as such, more a philosophical discussion. Maybe it's more of a subconscious thing...
Either way, like others on this thread, happy with the results whatever methodology you adopt.
1 Like
Whoa, this thought all by itself makes an App Store impossible if that is a constraint. What, we have to telegraph what we're doing so we don't step on some well meaning soul's toes? Or worse, stand accused of ripping off someone's idea and putting him out of business? Consider HubConnect and Hub Mesh. All such 'rules' would do is stifle everyone. Ooh, I better not do X because Hubitat is planning that down the road -- so X doesn't happen; or from our side, we better not do Hub Mesh because of HubConnect.... etc.
5 Likes
And support for blind users.
3 Likes
I get what you're saying. And Hubitat isn't at the size (yet) where it has the luxury of leaving some add-ons to developers.
But I'm glad you raised the example of HubConnect and Hub Mesh. Not that HubConnect is commercial, but if it were, then a value added service it currently provides that Hub Mesh does not, is the ability to connect hubs across networks. And also, the ability to connect ST to Hubitat (but that's of diminishing utility). And its provided this service for ~2+ years before Hub Mesh became an option. That's plenty of time for a developer to have recouped costs.
Just like Dashboards are an option that satisfies most needs. But Sharptools and ACtionTiles are choices available for those who need them.
3 Likes
I agree the condition on success being tied to the outlining of a roadmap is a stretch, but at least in terms of an enhancement to the HE platform, a built-in method for sourcing Community-developed add-ons could be a selling point, though not a major one I would expect.
Yep. Makes it very problematic. Many headaches, few rewards. Endless bickering...
3 Likes
So which release will it be in? 
Fair enough, plenty more important features for you guys to focus on, happy to keep tinkering away....
Not sure what you mean. Sometimes the code I write doesn't do what I want it to do, but that's generally not the desired outcome 
Apparently not. I made a feature request to the HE devs, and if there was a way to do it already I'm sure he would have pointed me in that direction.
I assumed that was the case. I suppose unrestricted access could lead to all sorts of undesirable things, and turn into a support nightmare.
Nevertheless, it would be nice if some sort of "advanced you're-on-your-own" mode could be switched on that would remove all or most restrictions. I'd buy a second hub if that were available (perhaps even pay more), and leave the important stuff on the non-advanced mode hub.
Such an "advanced" mode could have an agreement you had to check, basically saying "don't even think about contacting us for support if your hub is in this mode". Still, probably more trouble than it's worth for the HE devs I'd guess.
I agree. Everything they have ever said publicly re: reconsidering fundamental building blocks of the system in the interest of satisfying power users would suggest they will never do that. But anything’s possible!
I was referring to how you were quoting specific code that was not working as an example of not being able to do what you wanted, when it may just be the case that you need to do it differently.
Looking back at my post it's a little petty and / or pedantic. I probably got hung up on the use of very specific issue to disprove a more general statement about the flexibility of the HE platform. My thoughts at the time were that just because one piece of code does not work, even if it produces an outcome that goes against some of the claims made about the platform, it does not mean the outcome cannot be achieved.
All that said, your last statement about how you haven't found a solution may trump some of what I have said above...
Simon
