Writing your own "rule" apps worth it?

This has been discussed a few places but thought I'd bring it up here.. Due to performance issues, desire for more control, and a general curiosity I was thinking about rewriting my RM rules as apps (maybe parent/child apps).

I realize this is not for everyone but wanted to get people's thoughts on this.. Is it worth it?

3 Likes

Highly recommend it.. I find my rules that I have converted to “apps” are so much faster... RM is a wonderful tool, but it is very high level and as such more resource intensive than a groovy based app.. I still use RM for my small rules, but have converted all my complex rules into direct groovy apps

4 Likes

For me it was definitely worth it. I started with over 100 rules. Then I started writing small apps to replace specific types of rules that I needed. Some of them Ive released, some I have not. More to come when time allows.

BTW, I'm down to just 10 rules :grin:

5 Likes

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 :wink:.

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..

https://docs.smartthings.com

Most is relevant here.. And the development documentation wiki here at;

https://docs.hubitat.com

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.

image

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. :grin:

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