A Hubitat "Convert" here

Why Hubitat Elevation
1

My Hubitat Story -

I was an Iris user for about 2 years. Wasn't particularly happy with it, but learned to live with it nevertheless. Late last year I decided I needed something more reliable. What bothered me most about Iris was that it was heavily dependent on the internet connection. So, I started looking at Samsung ST, but there was no clear answer about what is local and what is on cloud. I really didn't understand why something that could be simply run locally needed to be run on the cloud. That is when I heard about Hubitat. Bought it because of the "fully local" operation and great reviews. Spent a day playing with the Rule Machine and lost heart and gave up on it thinking I will figure it out later.

Then came Iris' announcement about imminent suicide. It was already too late to return the Hubitat, so I decided to "figure it out".

I am a Java programmer, so I decided to completely ditch the RM and just write the groovy code for it. Wow ! What an experience !! My Hubitat is now really coming together completely on code that I wrote myself to make it work the way I want. I am in love with it now. So far, I have about 5 motion detectors, 3 door contacts, 2 keyfobs, 1 siren, 1 chime and 3 outlets - all working in weird fashion (the way I wanted it). My wife goes crazy at times, but I love that too.

Anyone who has the remote inclination for programming should just code this instead of wasting your time with RMs. And for those who don't have that inclination, pick up one of these to develop that inclination. You won't regret it !!

6 Likes
2

Glad to hear you're enjoying your Hubitat Elevation Hub.

As a programmer, I'm not sure I'd call writing RM Rules "wasting your time" though. Once you get the hang of it, RM is a very powerful tool. Custom code is the ultimate in terms of flexibility... but sometimes I just want simple, out of the box functionality.

Have fun! And please share some of your work as examples for others to learn from!

3 Likes
3

What chime do you use?

4

I have said the same thing over the last year. I write all my own apps. I have also taken a number of community apps and rewritten them to how I like them. I love the fact that I can strip out all the extra stuff and add in new features I need whenever I want. I have also been able to get rid of a few node servers and write them directly in groovy. I don’t think I have any node servers left running.

Once you get the hang of writing your first app you copy and paste a lot of code over to a new app.

Welcome to the community.

5

Welcome and I'm glad you found something that works for you! This is a fun hobby for sure especially when you feel like you can build improvements into it.

I would be careful to blanket statement that RM is a waste of time though. I use it all the time and I have an extensive software and not-so-extensive-hardware background (I've built a few Wifi devices from ESP8266s and wrote drivers for them among other things). I love the ability to have and use both RM and custom apps/drivers. There are definitely coders and non-coders who understand, appreciate and use RM.

3 Likes
6

If you build up a "library" of common functions/patterns then creating new rule apps seems fine I guess - cut and paste. Sounds like a fun challenge. One issue is as with everything the more you add the more complicated things become. Also you are the sole maintainer - a "silo".. which can be good or bad depending upon your use-case.

For me I prefer to let HE handle the simple stuff - it just saves a lot of time and effort debugging etc. Also WAF is higher when I'm not messing around with code all the time.

But that's what's really nice about this platform - the flexibility for all of us to do what we want! - within the framework and constraints of the system of course.. :grin:

3 Likes
7

I think like programming languages, that's why I was so stuck on WebCoRE.
I get where you're coming from!
Welcome!
Maybe you'll make some cool Apps or Drivers.

1 Like
8

After getting some experience with Hubitat, I've found that I use RM for very simple if-this-then-that logic, but if it gets more complicated (like if it would require multiple rules), then it's better to pick a combination of devices/apps that better matches the abstractions I want. Or if the rules aren't immediately understandable at a glance. That's an indication that a "rule" is the wrong abstraction level.

Example:
I wanted to turn lights on if my Ring doorbell detected motion. There wasn't a direct Ring integration for Hubitat, but there is one for Alexa. So I want to hook those up somehow.

First attempt: I need to push the "motion" value in from Alexa to HE, and Alexa really only understands switches. So I make a virtual switch that is exposed to Alexa. And in Alexa, I make routines to turn it off and on depending on camera motion.

Ok, but the Motion Lighting app in HE depends on the Motion Sensor capability. Not the Switch capability. So my first attempt was I made a couple Rules in RM that would translate the virtual switches values into values of a virtual motion sensor.

Here's the problem. Now I have two virtual devices in HE. And I have some random rules that are confusing. They only deal with virtual devices, so it's harder to understand what they mean for the physical house.

Second attempt: Instead of having two virtual devices, use one virtual device that implements BOTH the Switch and Motion Sensor capabilities, and always keeps the states synced internally.

This is better for a few reasons:

  • Alexa gets to deal with a single device it understands - a virtual switch.
  • The virtual switch/motionSensor in HE directly corresponds to the real state of the Ring motion sensor device. It's ~barely~ virtual.
  • The Motion Lighting app can hook directly to that one virtual device.
  • And it didn't require any rules in RM.

Basically, I find I don't favor "virtual" rules. If a rule only involves virtual devices, it's probably not the right abstraction.

And I don't favor situations where it takes multiple rules interacting together. For example: I had several lights that I wanted to ALWAYS be in sync. If you hit one switch, I wanted every other one to go on/off together with it. That could be done in RM, but would require multiple rules. It felt like the wrong abstraction. That's why I created my Switch Bindings app. The abstraction with that app is just "choose a couple switches/dimmers, and the app will always keep them in sync from then on."

Examples of things I DO keep in RM:

  • When I arrive home, open the garage door and unlock the inside garage lock.
  • When everyone has left the house, verify the door locks and garage doors.
  • If I unlock the garage at night, turn on the lights in there.

These are easy to read and understand, and aren't purely virtual.

YMMV. I'd love to hear how other people decide what to do in RM, versus in apps and devices!

1 Like
9

I'm ok with the Lego's approach. I have no visceral reaction to creating multiple rules. I name the Rules so that they sort together. Having come from SmartThings and WebCoRE, learning RM using the "bite sized" approach seemed to make it easier to learn.

Obviously it's personal preference, and I chose to not learn App development first, and just get the lights working. :smiley:

6 Likes
10

Great idea, naming the rules so they sort together! I am going to have to do that...

11

Exactly:

image
image942×552 15.9 KB

4 Likes
12

Exactly:

image
image.png792×672 20.6 KB

2 Likes
13

As a side note, I also prefix them with "Rule" so I can distinguish them a bit more in other apps and places they appear. I do the same with most apps.

image
image.png806×385 10.5 KB

1 Like
14

Dome Siren DMS01.

1 Like