Love Hubitat but find it very fusting on creating rules, Couple times I tried to create rules that didn't work the way I thought they would or in the middle of creating it I get an unknown error and have to delete the rule and start over. I know other people have created rules that I would like to use. I also think I learn better if I can see how someone else is doing their rule.
Eh, I don't think so.
By the time you do the 100 clicks it takes to change all of the items that need to be customized in a rule, it would often be just as easy to make it from scratch.
In my opinion what they need is a text editor for rules, instead of GUI only. 
That would cover the ability to share AND the ability to edit without 100 clicks.
15 Likes
I agree text editor would be easier
1 Like
I mean, I'm fine if they make a way to share rules. But with the GUI the way it is now, I don't even bother cloning my own rules in favor of just making from scratch - it is often quite a bit faster, just due to how the GUI works. I just pull up the old rule in one window as a go-by, and make the new one in a second window.
I'm quite happy with what I can get done in RM4. I simply wish there were a way to do it without SO MANY CLICKS. 
On one of my lighting rules I stopped counting at 175 clicks I had done to make the new rule. That's a lot of clicking.
4 Likes
Even the rule clone thingy is cumbersome, like @JasonJoel said, with the way it erases variable comparisons and expressions when you change the variable.
2 Likes
Not to mention that it makes the Device In Use By section inaccurate at best, or IMO, useless, as it "remembers" the old device(s) from pre-cloning.
Agreed, 2 windows, and redo from scratch.
1 Like
Cloning is great though if you're trying to tweak a rule or improve it. That way, you don't lose what you already have. Quite a few times I've trues to make it better just to screw it up and then not been able to get it back EXACTLY the way it was before. Or two days later I realize it worked better the other way. So, cloning is definitely useful depending on the situation.
5 Likes
I have an expectation that I'll need to change the devices and variables on a cloned rule. But I hope that by changing the device or variable in the condition or action, that I don't have to rebuild all the details around the condition or action. That for me, is where the UX goes bad.
For example, if you have a variable in your rule and you're doing variable math on it, when you select a different variable to do math on, it wipes out the variable math in the rule, which has to painfully be setup again. Seems trivial, until you have several points of maintenance in the cloned rule that behave that way. Added to the pain is the sluggishness of the UI when building out the rule.
2 Likes
So agree with this! Especially when changing from one device to another device of the same type. I really wish the rest of the action would stay the same. I usually end up adding a new action so I can see the parameters of the old one, and then deleting the old rule.
I also really wish that when a device was no long used in a rule, the rule would disappear from the "used by" section of the device page. It's a pain to have to double check every used by rule to see if a device is really used by it.
I'd love a text editor, especially when cloning rules and then having to click-change a batch of device names that could be done with one or two search-and-replaces.
2 Likes
Agreed. It wouldn't need to be fancy. Just an xml or json representation of a rule that I could edit.
1 Like
Yeah. they might be (probably are?) using device ID #'s behind the scenes, but even with that I can find the # and search replace that...
There is much more to this than meets the eye. Are you thinking of this as a way to share rules with other users? What is your goal?
If I could dump rules into a text editor, perform a find/replace on a device and change it in the file and re-upload it would be very helpful.
This gets around having to use the web-based editor to modify existing conditional statements, which can be very tedious.
2 Likes
If a text editor is "too complicated", just a way to use our favorite text editor and inject the result as a new rule.
Agree, I don't mean for HE to add another online web interface. That is a lot of work.
I would assume that all these rules boil down to some type of script/configuration/language which is running under the hood. Just peel back a layer an let users see this detail.
This assumption is false. There is quite a bit more complexity than you are aware of. Even if a rule were written out, substituting devices would not be just a simple thing to accomplish. The effort for a user would be just as tedious, in a different and more obscure way, more prone to error, harder to document, etc. So, it would require yet another online interface to make it easy to use.
Best analogy would be going from a high level language, to editing binary object code or assembly language code. It's all there, but not in a form easy to see and edit.
I appreciate you responding, but your explanation sounds like you are intentionally trying to keep from sharing what "is" HE.
I'm a programmer by trade, my day job is dealing with all sorts of languages on embedded devices. Many with hard real-time control and web interfaces. So this platform is very intriguing to me, but the interface to the rules engine--not so much.
Are the rules stored in a database in HE? Or just straight custom data structures? What is the scheduler you use to run?
1 Like
Take a look at the developer documentation. OK, it's sparse for Hubitat. Take a look at the "classic" ST SmartApp developer docs instead: Groovy With SmartThings — SmartThings Classic Developer Documentation
RM is closed-source, so we don't really know how it works, but it originated on SmartThings and the runtime environment is nearly compatible. You could write something like Rule Machine yourself if you wanted to. Perhaps try it and imagine the difficulty. 
Everything you choose in the UI is saved as a "setting" (presumably implemented as a Map, but that's an implementation detail we again don't know). Check out the cogs/gear icon after you create a rule and look at all the settings it generates. The difficulty, presumably, stems from getting a way to import and export rules in such a way that all of these would get set properly in a new rule. I'm not aware of any SmartThings or Hubitat app that has such a capability and certainly not one as complex as Rule Machine (the only app that comes close to this on ST is webCoRE, and that doesn't really work in the same way--it makes intermediary JSON that, aside from slowing things down and something I can guarantee Hubitat isn't interested in doing--does help a little with sharing). Rules are stored and executed like any other app because that's what they are.
If you find yourself needing the flexibility Rule Machine offers but want some re-usability, since you're a programmer, perhaps yo could consider writing a custom app instead. Apps are written in Groovy within the (very reasonable) limits of the Hubitat sandbox and the (very helpful) additions it runs on top of behind the scenes (e.g., again the implementation details aren't open, but apps are almost certainly all instances of some inherited class that provides the Hubitat-specific methods that are documented). You could also look at the wealth of community-created apps or consider whether a built-in app can suit your needs before choosing RM. And when choosing RM, don't be afraid to use multiple rules and keep things per-rule simple.
