I think I know the answer to this, but thought I'd ask anyway.
How practical would it be to eventually enable advanced users to write scripts combining actions, conditions and local variables, rather than all this pointing and clicking?
I would envision a special rule type with its own UI. Triggers would remain the same as today, but Actions, Conditions, and Local Variables would go away. In their place would be a script editor. Scripts would offer more advanced flow control such as switch statements. Maybe even the ability to call into user-created Libraries. Off to the side would be a hierarchal and expandable list of actions, devices and their children and properties. There would also be a separate list of system variables. Clicking in either list would insert that reference into the script. Or drag-and-drop, perhaps.
I'm guessing the Hubitat architecture would make this difficult, but I thought I'd ask.
Rule Machine is not a programming language. The logic in Rules are translated to database entries. Creating an interpreter to translate natural language into such entries is a formidable task; in addition, incorrect or undesirable entries could crash the hub's database.
In addition to webCoRE, which uses an editor that runs on non-Hubitat hardware, but runs automations on the Hubitat platform, Hubitat also interfaces with other automation systems that run on non-Hubitat hardware. Like Multi-System-Reactor and Node-RED.
Rule Machine exists so you can create custom automations without having to do this. But, as mentioned above, it is a point-and-click interface that happens to summarize your selection in something that looks like pseudo-code. Nothing about the interface itself actually creates code.
Purely opinion, but I personally feel this [see below] is an example of what the right choice for future redesign of the Rule Machine UI should look like. Anything else would be a step backward in usability. They also offer in-line scripting if one is so inclined.
Thank you! I was only vaguely aware of this, but I thought webCoRE required cloud access. Looks like you can run a local instance of the editor on a Linux VM.
Someone elsewhere asked me why I don't just go with HA. Because I've read too many stories about how difficult it is to get devices to work as designed in HA. Don't want that headache. But I also don't want to rely on any cloud services for automations. This looks perfect. Automations still run entirely on the hub.
In all fairness, I do think Hubitat Elevation IS amazing, but there's always been a rather significant need for UI/UX improvments in my personal opinion. It's far better than where it was in the beginning, but continuing to lose ground to the competition in regard to usability.
I'm conflicted. When I look at the pseudocode, I can see at a glance exactly what a rule is doing. Not so much on a flow diagram. But it's certainly prettier.
Not the best example. Pulled from their web page. I think this really boils down to how your throught processes naturally develop. It's not wrong to prefer how the Rule Machine UI is constructed, but it does take more time to learn how to build rules than drag and drop flows.
Flow type workflows are typically easier to build, but it's not untrue that they can become very large and pretty impossible to view on mobile. This is the reason Homey simply doesn't support their Advanced Flows on mobile. Not so much the case with Rule Machine as it is today. It's more difficult to build or edit RM rules on mobile than on desktop, but not impossible.
I certainly wouldn't want to see a carbon copy of Homey Advanced flows or Node-RED on Hubitat. What might be ideal would be a hybrid where one could switch between a flow type UI and the current method, with the added ability for scripting.
Yes, it is a programming language.
The way how this program is created and what the "black box" does for interpreting all the commands is a very different story.
Not exactly sure, I would call it a "programming language" - This is a bit syntatic, but I'm pretty sure their is no BNF definition or notation for RM. I'm not even entirely sure there is a formal grammer. YACC/LEX isn't going to work on RM text.
I'll give it a "interpreted command stream" (stored as a bytecode? in a database) and executed by an application RM (kind of, sort of like a JavaVM) - And while I like RM, I think considering it a formal language - is a bit of a stretch - I think Bruce has specifically said, in the past, that he doesn't consider RM a "language".
Not that any of this really matters, in terms of how "automation rules" or edited or visualized.
I saw and remember Bruce's comments.
But think about this a bit different way. Imagine you found on a street a piece of paper with
printed RM code and you know nothing about HE, etc. But you are familiar a bit with a programming. What you will think about this finding and how you will interpret what you are seeing?
Regardless of what you call it, the fact remains that the RM editor summarizes your selection as a sort of pseudo-code but does not -- as some people therefore mistakenly assume -- actually write any code or interpret this pseudo-code. Rather, it reads back the settings you've configured and does something in response when appropriate. This is ultimately the same as any Hubitat app.
That does, of course, involve executing some chunk of actual code at some point, but that is all the Groovy app code for Rule Machine itself (this is how the app, like any Hubitat app, was written). If you want to write code, Groovy is where you need to go, too.
That is usually what people are asking for when they make requests like the OP, not a formal discussion of whether RM per se is "programming" -- as interesting as such discussions may be from an academic standpoint.
What do you mean by "printed RM code"? Do you mean a screenshot of a Rule? Because there is no Groovy generated by RM for each rule.
If I saw a bunch of h2 database entries (which is what underlies RM), I would have no clue what it meant. If I saw a screen shot of an RM rule in the GUI editor, I would understand the gist of it, much as I would if I read any other text.
Indeed.
Needless to add, completely irrelevant to what the OP was looking for.
But given a formal background in CS, the meaning around the term "programming language" has specific and formal definition to me. That RM definitely doesn't meet. The generic and looser definition around "code" isn't as formal, in my mind.
Again, this is really a bit pedantic, and it doesn't matter in terms of more HE automations (rules?) are created, edited, visualized, or debugged.
