I have a few complex rules that are part of one bigger system or goal, but that involve multiple triggers each triggering different actions or reacting to different things as part of that goal, so they're setup as different rules. Currently I just make them with the same prefix, but it still just looks like I have more rules than I do, it looks unwieldy to see this monster list where everything is a parent rule. It would be great if we could group rules together, or have parent and child rules like on the device page. It would be great to see parent rule Goodnight and sub rules for things to do when Alexa flips the virtual goodnight switch, things to do when I hit the goodnight button, etc., all under the parent rule of "goodnight stuff"
I’m sure there are ways that a list of rule machine rules could be made easier to view, but I don’t think “parent-child” is possible here.
Rule machine is a parent app, and each rule is itself a child app.
OTOH I’m not actually a developer, so could be 100% wrong about that 
.
1 Like
Yes, some sort of hierarhy for sorting rules will be a big help.
Also RM is messing a case statement which will help to implement
elegant State Machines.
1 Like
Could you give an example of this?
Rules grouped by room someday would be super great. Hint hint!
I don't have an example for RM because there is no case statement in RM.
I am experienced EE designing FPGAs, so I can provide an example in VHDL.
(not sure this will be somewhat helpful).
In current RM you can use a numeric variable for defining (enumerating) states.
Then long chain of
IF(VARIABLE=0)
ACTIONS ...
I get what you are saying but I think the Parent/Child nomenclature isn't correct (at least by my perception because of how I view programs) I think it's more of a rooms kind of thing. You have a Labeled section called "Living Room" or "Goodnight rules" and that's all it is a label and then the rules you can assign to that section simply for sorting purposes. The rule would work the same regardless the the section. So I think @waffles has the more perceived approach. That said... Not sure how much of a priority that would be for them
A case statement would be most convenient.
1 Like
I think I'd describe it as a more elegant way of doing if... else if... else if... etc. I'm dating myself but here's what it would look like in Pascal... (sorry, but you get the idea).
program checkCase;
var
grade: char;
begin
grade := 'A';
case (grade) of
'A' : writeln('Excellent!' );
'B', 'C': writeln('Well done' );
'D' : writeln('You passed' );
'F' : writeln('Better try again' );
end;
writeln('Your grade is ', grade );
end.
Maybe just an explanation in English (not code) would be fine. In other words, what are you trying to do that cannot be done?
1 Like
It appears he is trying to grade homework with Hubitat 
1 Like
Nah I just throw papers down the stairs like everyone else.
2 Likes
That is how I do it. Does the top stair get the "A" or does the last stair get the "A"?
That's why we need the CASE statement so badly.
CASE (martini)
martini=1
choose top stair
martini=2
choose middle stair
martini=3
choose bottom stair
and stay there
ENDCASE
Hi Everyone,
I am not sure how to describe why CASE statement is better than chain of
IF-THEN ... ELSE IF THEN ... END IF statements.
As I mentioned, I am experienced EE.
In the Programable Logic world using CASE statement(s) instead of IF-THEN ...
generates smaller (and as a result - faster) logic. Plus code is much easier to
understand an maintain.
In current RM implementation State Machine(s) could be designed with
IF-THEN statements but code will be spaghetti-like. Plus you will have to
create minimum two rules. Using CASE statement will significantly
simplify code readability and maintainability.
1 Like
IMO, you are expecting too much from RM. It is not a programming language, was never intended to be one. Your needs cross over into the realm of custom apps. Groovy has a 'case'-like statement, and there is an API to invoke RM rule actions from code, so you'd implement your state engine in Groovy, but do the work on devices in RM. Groovy is an easy to learn programming language.
1 Like
Well, may be.
The problem is - I am very experienced EE but my programming skills are
very limited. But it is what it is. I guess, I have to learn Groovy and dive deeper
into SW development As of today I am good with Assembler (yes) and C/C++
programming. I am quick learner. So, let me try to become a good SW designer
as well.
Talking about all these Drivers and Applications.
I am very surprised, but why every device needs an individual driver?
Why not to have Universal (or at least self adjusting) Driver for all devices.
Correct me if I am wrong, but every Device reports its Capabilities. Yes, no?
In this case why not to create self adjusting Universal Driver?
BTW, about 15 years ago I was about to start my own company to create
something like this. I created a presentation and everybody who saw it
was impressed with the idea but I did not succeed with the financing.
I am very technical person but all this administrative overhead is not for me.
I am still wonder what is a show stopper in order to create self adjusting
Universal Driver?
Second question is - why do we need many similar Applications instead
of one but very powerful Rule Machine?
Integration with all this Clouds (I really hate them specifically for the HA)
is a different story.
The matter o fact, I moved all my automation to the RM.
It is powerful and really good.
But, yes CASE statement will be a BIG help in order to simplify code(s)
and make it more manageable and intuitive.
Maybe i am spoiled with my EE experience.
I don't know how I can design very good HW if VHDL and Verilog HW
design languages will not have CASE statements.
Devices don't 'report' their capabilities. That is an interpretation layered onto a device by its driver. Many devices share a driver, others don't. The driver provides a mapping from what the device physically reports, into the capability / attribute / event abstraction of the hub platform. This abstraction in turn supports the ability of apps to not have to know the specifics of each device. A universal driver would be inherently inefficient in the one place you want efficiency -- the mapping to and from the specific hardware interface for the device. Considering that we have hundreds of drivers, combining all of those into one massive case statement is not a good idea.
The need for different apps instead of one super app has to do with specific needs. For example, while RM could implement Motion Lighting, it would take multiple rules and complication to do so, whereas ML is able to offer the specific needs for this very specific use case. Similarly, HSM provides a user interface model and paradigm that is recognizable, and fits that use case. Etc... RM is a multi-featured app, but over the heads of many users. Consequently, simpler apps were introduced. Choice is good. "Your use case is not my use case,"
I'm sorry but I don't agree about your desire for a case statement-like control structure in RM. Under the covers, this would not be more efficient, but less so, and case statements are basically a realization of sequential IF-THEN-ELSE-IF... Again, I think you are way off base in thinking that a case statement would be helpful in RM, that in fact the opposite is true, RM is NOT a programming language, rules are not 'code'. It is a means of evaluating conditions and taking actions in an event driven system. Trying to push it beyond the creation of basic automations is, imo, a mistake. There are users who create humongous hundred action rules, and spend days and days getting them to work. As its author, my largest rule is less than 8 actions, and most are smaller. You're wanting to go in the wrong direction -- towards complexity. Instead the key to a successful automation system is simplicity - KISS.
You should know that RM began as a community app several years ago in SmartThings. I implemented the first version over a weekend. I had learned Groovy perhaps a year prior, and was still learning it then (and now). What you see now in RM is the iterative improvement of the app through hundreds of iterations.
Learn Groovy. Take an example app from our public repo and modify it to start...
3 Likes
I am coming from the hardware design world (started with vacuum tubes, then transistors,
then ICs, then Micro Processors/Controllers and finally FPGAs with embedded micros) and
I know very well the difference between HW and SW implementations for the same logic.
In HW everything is happening in PARALLEL but in SW everything is SEQUENTIAL.
This is true even for the multicore/multithread processors (lets not to dive deeply into the
details).
So, in HW world CASE Statement is very simple DECODER. IF-THEN-ELSE IF Statements
are far more complicated logic with priorities. Regardless both will execute on a single Clock
(Clock is an Event in a HW world).
In the SW world CASE and IF-THEN_ELSE IF both will be translated into sequence of CPU
commands. The efficiency depends on Compiler. The experienced SW engineers told me
in C++ SWITCH-CASE construction is more efficient and faster vs IF-THEN-ELSE IF
construction even both are sequential.
it is what it is but implementing State Machine with CASE statements is much easier
to understand and maintain.
I am not going in the wrong direction towards complexity.
In all my HW designs the SIMPLICITY and EFFICIENCY are always highest priorities.
And of course, this is absolutely true for the successful automation, no doubts.
But all these depends on Platform and Platform Implementation.
All my previous HA controllers did not have any Drivers and applications at all.
All what they had - is a some sort of Event Driven Rule Machine.
I love Hubitat but I found it very messy with all this Drivers and Applications.
Fore sure this is an ideal toy for the experienced SW folks.
As a result now I have to learn Groovy (and sure I will) because I have to
adjust or even design some Drivers and maybe even Applications.
I have no idea how ISY guys achieved this goal but once you install new
device ALL device capabilities immediately was exposed to the whatever
equivalent to the RM. So, sort of Universal Driver or Automatic Driver Creation
is definitely doable/achievable.
Bottom line:
I don't want to start here potentially endless discussion.
Everyone may have personal opinion and here is mine.
I love Hubitat "as is" and yes, specifically RM.
(I already moved everything to the RM.)
However I think it is overcomplicated with all these Drivers and Applications
for the common users (not for the experienced SW engineers).
There are many things which could be dome more user friendly.
For instance, all these pull-down menus and gassilions of mouse clicks
definitely needs improvement.
BTW, I already developed Carpal Tunnel syndrome because of these
enormous amount of mouse clicks. But before I was using PC with
mouse for 40+ years without any problems.
I think if they tailored this entire platform to your specific needs, the customer base would consist solely of very experienced electrical engineers.
I don’t see the upside for them as a company, or the rest of us as users.
6 Likes
