I am sure 2.2.9 SW is on the way.
RM is a key application for the HE.
Without the RM HE will be far less attractive for many common users
and will be more shifted to DIY(mostly for SW developers).
Many BIG Thanks to @bravenel for the RM existence and maintenance!
Also RM GUI is not really user friendly but visualised RM Rules are very
intuitive and straight forward (well, for the people who are comfortable
with Logic creation).
Here are my couple suggestions how RM could be improved:
If this is possible why not to make RM as a HE native application?
All variables already became HE native.
The same better to be done for the RM as well.
I am not a SW developer but my good guess, it will be much easier
and simpler to implement all RM functions if RM is a HE native app.
Since everything could be done by selecting "Run Custom Action"
why not to start rule creation right from this point, i.e. jump right
into "Select capability of action device" bypassing two first
pull-down selections:
Not sure what you mean by "native app". I assume by "All variables already became HE native" that you are referring to Hub Variables. The Hub Variables setting page is an app, just as RM is an app. The underlying data structure of Hub Variables is implemented in the hub platform. Putting RM data structures in the hub platform would not be a good idea, as this is much too dynamic and changes frequently.
You have made this suggestion before, and it is not a good one. "Your use case is not my use case" applies. You personally are of course free to always use Custom Action if you want. But there is more overhead associated with Custom Action for both the UI and runtime of a rule, less data type checking is possible, it is easy to mess up with malformed parameters to device methods and it lacks the power of many of the more useful actions in RM.
The RM UI can be difficult. This arises in part from the app UI framework, in part from the complexity of any app that supports the breadth of uses of RM, as well as the inherent difficulty of expressing logical rules in any UI. Were we to upgrade the app UI framework, RM would have to be completely reimplemented, as it is seriously intertwined with current app UI framework. This is also true for all other built-in apps. So, while we might upgrade the app UI framework going forward, it would also require new implementations of all of the built-in apps. This will not be a small undertaking.
As I mentioned, this was only my suggestions based on previous experience with HA.
Long time ago I was using X10 with JDS TimeCommander (this device was base on
i8085 CPU with 1KB EEPROM and very small RAM, do not remember what size RAM was).
But it did have very intuitive say RM. Interface was very simple and straight forward.
When Insteon came on the market I switch to Insteon with ISY994i PRO Hub.
Insteon itself was very good idea. You could create various scenes completely
independent from hub. Of course hub was required when you wanted more or
less complex automation. Insteon was/is a Power Line + RF communication.
Insteon devises is very tricky to pair but one this was done the Insteon Network
was stable and reliable.
ISY UI was using Java Component in the Web Browser (I considered this downside)
but again after all ISY UI was very simple and intuitive.
On the other side, HE RM UI (not rules) is very complex.
When I started to create Rules in RM I new exactly what I was needing and looking
for but it took me a while to realize all this dynamically created menus relationship.
And even now I cannot remember all UI dependencies and it still takes time to
find things in this forest of pull-down menus.
I do not know the platform details, how many different SW Layers is involved,
what platform limitation are and how difficult to make a drastic changes
specifically in the UI area
My whole point is/was - the RM development (UI specifically) better to be pointed
toward simplicity of use for the common end users (not a SW gurus).
Unfortunately "as is" this is not a case.
The created Rules in JDS TimeCommander, ISY994 and HE looks basically identical.
But HE GUI is far less intuitive among these 3 toys I mentioned above.
PS.
I guess this discussion is pointless and better to be stopped/closed.
May I suggest referring to this section of the docs until you get used to where things are? https://docs.hubitat.com/index.php?title=Rule-5.0#List_of_Actions. I've been using Hubitat (and RM) for years and still guess (or a least click) wrong sometimes, but you do get used to it.
I know I've suggested this before, but you might also be interested in writing custom apps. If nothing else, it will at least give you an idea of what the app UI framework looks like--and why some things that sound good may be difficult to implement, or maybe you'll see a way to do something cool that no one has thought of before.
(For things like rules, I see basically to ways to do it: a "device-first" approach like webCoRE, though its UI exists entirely outside of Hubitat and can do lots of things it can't; or a "capability-first" approach like RM, where you first narrow down what kind of action/command you might want to run and the UI then scopes the device selections to ones that might work. It's not officially supported, but maybe you should check out webCoRE if you haven't. On Hubitat, maybe the UI framework will be revamped some day to make "dynamic" apps like this easier to write/maintain--the framework it's based on was originally designed to display relatively simple UIs in a cross-platform mobile app, not a webpage, and this initial near-compatibility with that model was probably a hue draw for Hubitat in its early days and possibly still now--but I digress...)
Oh well,
Thank you for the suggestion but my very strong preference is not to read any
docs at all. Very good design should/must be self explanatory.
I am EE but I am doing a lot of C/C++ programming for testing my creations.
Usually the communication is very old and lowly RS232.
I am paying a lot of attention on the UI and so far this was I would say, successful.
I did not write any single line of documentation and did not have any questions
how to use all that embedded test utilities
All UI is done on my device/board. All user is needed - is say PuTTY or similar
Serial Terminal Application.
Simplicity of use and intuitive navigation is a key point.
I guess, I have to start this at some point.
But since I can do everything what I want in RM (and I am using only RM at this time)
I am to...o lazy to learn another programming language and switch from designing
electronics to designing SW (but of course, this could be fun).
The least what I want - is to introduce another device like RPI, Arduino, ESP286
to my setup. All these extra devices will reduce reliability.
Forget about Cloud-based services but my BIG dream even to get rid from Hub
as well. As I already pointed out in my previous posts - Hub is a "Single Point of
Failure". Why I would add another something into this equisin?
My goals and points are toward simplicity, not complexity.
And as I said, as of today I can do everything in RM.
RM is a flagman application in the HE. Having RM rock solid, simple and intuitive
should/could be very solid improvements for the HE platform.
Preference, sure, but maybe make an exception when you're dealing with a complicated tool?
You don't need one to run webCoRE. All "pistons" (rules) run locally on the hub after creation; the editor is, by default, the only piece that doesn't. You can run that locally if you want to, but there is no need, and it has no effect on the final result.
Have you explored Basic Rules and Simple Automation Rules? These are oriented towards beginner users and offer much simpler interfaces. Yet, they can perform sophisticated automations.
Rule Machine is unique in that it's purpose is to expose virtually all capabilities of the platform for automation. By definition, that means there are lots of choices and a good deal of complexity. It is not needed for most common automations. For example, Motion Lighting is much better than RM for motion controlled lighting automations. Both Simple Automation Rule and Basic Rule are better for basic automations. RM is, in effect, a specialized tool, not the tool for most users for most automations.
Ops, I am sorry, I messed up with Node Red.
But again, I am somewhat happy with RM "as is'.
Yes, but only for the very complicated things which do exist but not on a surface.
All basic things must be very intuitive and must not require reading any docs.
Creating basic IF-THEN-ELSE statements in RM is not in "complicated" category.
But even this was not intuitive at the very beginning.
