Very cool!! Thanks for your input - I was thinking about doing my rules under the parent/child model.. my thinking is to keep things organized under one main app. Also can share some resources that way too...
2 Likes
I haven’t “released” all mine either .. But if you watch my github .. I do upload things that work for me.. Just don’t post a release on the simpler things.. But you may find things there that you can slightly modify to fit your needs..
2 Likes
While HE was not intended to be a development platform.. I feel this is one of it’s biggest strengths. Local execution of user generated home automation code..
2 Likes
Is there a guide somewhere to get started on Groovy (especially for Hubitat)?
2 Likes
The flexibility is awesome. Okay so I will give it a shot then. Thank you!!!
Was also thinking about setting up a "library" of sorts in the parent app for general stuff. Wondering if this would be a good thing or not.
3 Likes
It's kind of all over the place. Best to look at already created apps..
Here's a start:
Also check out developers like @bptworld and @bcopeland's stuff as examples 
.
HE Documents:
https://docs.hubitat.com/index.php?title=Developer_Documentation
Also SmartThings classic documentation:
https://docs.smartthings.com/en/latest/
E.
3 Likes
Not so much a getting started guide.. But you can reference the getting started guide on smartthings..
Most is relevant here.. And the development documentation wiki here at;
1 Like
Also, try node-RED. I'm slowly converting my RM apps into NR and after the initial struggle of understanding the system, I find it's not too difficult to program and much easier to edit than RM. Using a Raspberry Pi 3, I find execution speed hasn't taken a hit. I may want to upgrade to the newer RPI 4 in the future though.
2 Likes
I've been eyeballing that from afar as well.. so much stuff to try. I was also kind of interested in revisiting webCoRE.. I do have a spare hub lying around... so many possibilities it really is overwhelming.
1 Like
Spare hubs are excellent for development.. you can test your code without affecting your production hub..
2 Likes
I re-wrote all my motion lighting rules into custom controlled apps. This is the response time I get for these apps.
This is logging when the app receives the sensor report and then the app closes after the commands have been sent to the two lights with independent levels. So, this takes all the sensor timing and device timing out of the picture. That's less than 200ms from start to finish. That's spinning up two different drivers, one z-wave and one zigbee. This is exponentially faster than it was when using Rule Machine. And it performs EXACTLY how I want.
And as far as a dev hub...you can. But I pulled a "Bruce". I do all my development on my primary hub. I think that a dev hub is a must-have if you are doing driver development because you could cause an issue with communication with devices. When developing apps, if you leave nothing in your "initialized()" method except for "unschedule()" and "unsubscribe()", then simply rebooting the hub will kill any major issues you might cause with things running away with themselves. Then when it's working correctly you can go back in and fix the initialized method to what is necessary for the app when the hub boots up.
3 Likes
Yep... Exactly why I have a dev hub.. I once had a command so bad (while learning zigbee) it shut down the whole zigbee radio... That was the day I ordered my dev hub..
1 Like
I forgot to mention....another reason why I don't have a dev hub for app development....I live alone. So, WAF is always at 100%. If I screw something up and have to reboot my hub, I'm the only one affected (since I'm not working on my hub when anyone else is here). I think that's a big factor as well. I don't have a wife or kids barking at me that lights aren't working correctly while I'm working on my apps.
3 Likes
That is very interesting about the motion timing thanks... WAF can be a good or bad thing. Keeps me somewhat grounded in my pursuits. I do kind of envy your freedom in that regard however.
2 Likes
That’s handy
1 Like
You just might have talked me into learning groovy. 
2 Likes
I really do recommend it .. It's not a hard language to learn .. and the HE platform does some crazy fast groovy execution... Even though this was not their intended purpose .. It is one of their biggest strengths IMHO
2 Likes
Just to touch on a few points here.
RM and all the applications that we publish are written in groovy, and they are written the exact same way as applications written by users, sure there are one or two internal shortcut methods that for security reasons only work with system applications, but that's a very very short list.
RM is big, given the options that it presents, it's going to be big, there's no getting around that, with flexibility comes complexity.
Personally I only have two custom apps that I run (one to manage dimmer levels, the other connects my hubs (pre HubConnect)), having said that my rules are simple and seldom exceed one if/else block.
So the point here is if you have a significantly sized Rule and it's correctly written and you aren't happy with the execution speed, sure, creating a dedicated application to replace it is going to run faster.
In almost every case a well written specific dedicated app is always going to perform faster than a larger more complex swiss army multipurpose app...
Having said that not everyone wants to write or needs to write code, but with Hubitat you have the option to create exactly what you want if so desired...
9 Likes
It's certainly a tribute to HE's flexibility and design that it can handle both scenarios..
4 Likes
My intent was in no way meant to put any negativity on RM.. I am seriously impressed with RM and it's capabilities.. And for a non-programmer it is absolutely the way to go.. And I still use it for my simple rules.. But the power and speed behind locally executed groovy code is amazing for more complex actions..
Writing an app for every simple rule I have would be ridiculous..
4 Likes
