I'm completely positive the list of "useful production and delivery platform" improvements is 6-8 years long. 
I want better UI, RM, New User wizards, on and on, over yet another language option.
1 Like
I'm puzzled by the negativity to the idea of providing a better-supported alternative to Groovy.
Agreed! Though I hope Maker API could get a little love, too.
Probably because it is viewed as "nice", but not "needed". And there are many "needed" enhancements that would not get done if they work on your "nice" request. Developer resources are limited/finite.
I don't think anyone is against options, per se, except that they use resources we want to be used for other things. 
1 Like
I don't think there is any negativity but rather that the HE system is built with Groovy. Adding another compiler, layer to support another language could cause negative performance and more difficulty in troubleshooting.
4 Likes
No negativity here. Groovy was chosen as it's an easy path to port from SmartThings. Nothing wrong with alternatives, but as the core language of choice, I believe most of us would strongly prefer greater device support along with a focus on fit and finish before other languages are added.
If the maker API is too limited, create an oAuth endpoint and send the events to your NodeJS box. You can do anything you want to do that way, and you don't have to wait for the devs to get around to adding that support.
I'm trying to understand the hostile reaction. Increasing developer effectiveness is important. I've been limited by the need to master yet another language, Groovy, that lacks tools and support.
JavaScript can increase the size of the community and the ability to add capabilities.
I just want pizza. Can Hubitat provide?
3 Likes
I think you can do that with Dominos IFTTT channel 
1 Like
I should add that I'm thinking more in terms of TypeScript with intellisense than simply JavaScript. My goal is to make it simple to do simple things. That creates an incentive to learn more to do more.
I'm not looking to automate as much as to be in control. Much of the mechanism inherited from Smartthings is based on the idea that their engine is necessary and valuable. I did write Groovy code to work around it.
The maker API is a good example of doing simple things simply. Having similar capabilities running on the Hubitat with the added ability to respond to events would be very powerful. Even more so if I could use tools like Visual Studio to get leverage and save debugging time.
I hear you, but you have to accept that from a development sense Hubitat likely WANTS the system to be closed - that's why they won't give us the SSH password 
. If they start letting users run other things on it, support questions go up exponentially as they interfere with the core system.
Doing it on an external system via Maker API is fully supported, and can do it in a way that isn't potentially painful for them, or compromise the core function of the hub.
1 Like
Again I don't think anyone is being hostile but rather just accept the environment that is being presented to the community. Groovy is actually a pretty good language which gets its language similarities based off JavaScript. BUT, that is truly where it ends. If you research other home automation systems you will see none of them use JavaScript or Java. Honestly probably because how easy it is for many "developers" to write very bad code. Java/JavaScript sorta just lets it happen and can bring operations and reliability to its knees.
Some examples from leading home automation systems that are thriving:
- Hass.IO uses Python and now heavy MQTT
- SmartThings uses Groovy
So it is what it is. Most of your knowledge about JS will naturally work in Groovy. Where Groovy falls short is what has not been exposed by HE. Web Sockets just became available to the community. Telnet just became available. So you just have to take what you can get and make requests for advancements in Groovy that makes sense. One advancement that has not been implemented is the ability to make remote class object calls to community groovy code hosted outside of HE. But eventually as the HE team continues to meet their goals in delivering the best on-premises, local execution and most reliable smart home automation solution they bring new features to the environment. Some are apps. Some are app advancements (Global variables in Rule Machine [YES!!!!]). Some are development environment advancements. If you have a need ask the support team publicly and privately...BUT keep it positive and explain what you would like to do that you can't do today. They are very responsive and if the addition makes sense and supports the community then most of the time they divert efforts and invest in community recommendations.
Overall....embrace Groovy if you wish to use HE. But also contribute where you can.
We're coming at this from different perspectives. I've been writing my own home
control software for a few decades and see Hubitat as providing leverage in a larger context and not as a self-contained platform.
On SmartThings I did use Groovy to implement something akin to a MakerAPI (with notification). JavaScript would make it easier to tap into the larger world of tools and to contribute to the Hubitat community. (Even more so with TypeScript definitions).
1 Like
Oops -- ctrl-enter submitted while I was still editing.
I wanted to comment on your pejorative description of JavaScript and wonder how much was being driven by simply not liking JavaScript. I don't want to get into a fight over languages beyond noting that in the larger world JavaScript/TypeScript has been strongly embraced.
1 Like
I think all of that has been covered already in this thread.
In any case, you may want to email support and get an official feature request in the system. Posting on here is OK, but I've always felt that it is better to email support to ensure it 'gets in the system'.
Good luck.
Alas, I did a more direct reality check and it's not a priority. Perhaps if the developer community was excited by it but the excitement seems to be in the wrong direction for me ...
I am not trying to come across as being rude, so please do not take what I'm about to say as such.....
You claim of writing home automation code leads me to question why you chose Hubitat in the first place. Surely after all this time you've already created something that suits your needs. And even if for some reason you have not, why did you choose HE over OpenHAB or HomeAssistant. Both of which expose all of the underlying code and I believe HomeAssistant already supports a Javascirpt NodeJS API.
As I said, not trying to be rude, just trying to understand your perspective.
1 Like
openHAB is written in Java.
Hubitat is written in Java:
