Not sure I understand - different things happen on different days of the week all the time, don't they??
Sorry, didn't mean to hijack this thread... I'm done
Goodnight-Alexa
Goodnight-Button
Goodnight-Action
Goodnight-Nap
Etc
Messing around with basic things like listings of apps isn't high on our list of possible UI improvements.
4 Likes
I am sorry, I am opened a can of worms.
My point was/is:
CASE Statement is better readable and maintainable for designing State Machines.
However the same State Machine could be easily designed with IF-ELSE IF ... statements.
In HW this most likely will be slower and bigger but in SW it will be about the same.
Yes, in HW world CASE Statement will create much smaller logic.
However in the SW world CASE will end up with IF-ELSE IF-ELSE IF ... chain.
The big difference between HW and SW is:
- in HW everything is executes in parallel;
- in SW everything is sequential;
The concept of implementing a State Machine in RM is the mistake in this line of thought.
Analogous to wanting to build a house with a Swiss Army Knife.
I cannot design any good and elegant HW without State MacInnes.
The matter of fact, any CPU is a giant State Machine.
The RM may not be good for dealing with State Machines but is
wrong with State Machines in general?
Any Automat/Controller (not a weapon) is in fact some sort of State Machine.
Well, if you don't want to be more specific about what you mean by State Machine, then yes, Reductio ad absurdum.
Between thinking you need a CASE statement, and entirely uninformed ideas about how RM actually works, and comments about compilers and code efficiency of CASE vs IF-THEN-ELSEIF (none of which are in any way relevant), lectures about differences between hardware and software, it is impossible to know anything about what you are actually trying to do, and any comment about it is pointless.
5 Likes
I think we should go back to using assembler and jne/je statementsā¦.
2 Likes
I am sorry to ask this question, you don't know what State Machine is?
Did I get it right?
You are 100+ % correct. I have no idea how RM is implemented and how
many SW layers are involved between what I am seeing in the GUI
and actual executable CPU commands (final machine code).
First is OS, second is Hubitat Main Application (maybe multiple applications),
And somewhere in this chain a Groovy Compiler or Interpreter.
Plus whatever else. I can only guess.
I would like to understand what happens after I created a rule and
hit a Done button. Is the code created from using all these pull-down
menus somewhat compiled and injected in the machine code
(most likely not a case) or whatever Interpreter is involved?
If I new these little details many questions I have will not be asked.
And to answer you question what I am actually trying to do.
I am trying to create very robust, stable and easy maintainable
HA environment. Something like "set it and forget it".
I have all required hardware in place (switches, sensors, etc.).
Yes, periodically I am replacing devices or adding new.
My rules are also pretty much stable.
Again, periodically I have to change or add something.
That is why I do care about code readability and maintainability.
1 Like
Rules are not code, as has been mentioned a couple times. What you see might be considered "pseudo-code" that represents the actions you've chosen in a sort of human-friendly summary, but there's nothing special about what you see--they could make it display whatever they wanted to, and it wouldn't affect how the app works.
I wrote in another post an explanation of how Hubitat apps in general work (and again, I think you might enjoy that more in the long run, but the rules you posted in the other thread seem pretty manageable as-is). Rule Machine is also just a Hubitat app--albeit, probably one of the largest and most complex. But it still plays by the same rules. 
Incidentally, however, my comments were also regarding Rule Machine:
2 Likes
Thank you very much for the explanation and references.
It was clear for me the RM is not a programming language (even whatever is
displayed looks like a program) neither a compiler.
It is just another application.
But how application itself is processed?
At the bottom it must be something pre-compiled which runs under OS.
So, if I write my program in Groovy how it will be processed?
Is it a buit-in Groovy Interpreter or program is actually compiled?
I still donāt know what your automation needs are. If you absolutely need a finite state machine, Hubitat integrates, via MakerAPI, with the āoutside worldā, which could be running whatever you want, including a finite state machine.
From a practical perspective, for many of my automations, the outside world is an SBC on the same switch as my Hubitat. I use Node-RED, in which a finite state machine can be installed/used.
I think we should go back to using assembler and jne/je statementsā¦.
The most efficient code, for instance Interrupt Handles in OS, is still
written in assembler.
The lines of text that display selected actions in RM, are, as @bertabcd1234 observes above, nothing but a user interface means of providing visual feedback after the fact as to the interactive selections the user has made constructing the rule. They are not a programming language, nor bear any functional relationship to one.
These interactive selections that are made through the user interface while constructing a rule are used to create internal data structures. These data structures in turn guide what happens when a rule is triggered. At no time is there a translation to machine code, or to any code, unless one considers a data structure some form of code, in which case it is purely arbitrary and app specific.
Every app, including every rule, is comprised of four types of data structures. For any app, any rule, these can be viewed in their entirety on the App Status page (gear icon). The four types are:
Settings
Each choice made in an input during the app/rule construction results in a Setting. If a device is selected, the corresponding Setting references the device. If a Boolean on/off selector is switched, that has a corresponding Setting. Making a choice from a pull-down menu results in a Setting. RM is a very complex app, and as such encodes some information in the names of various Settings. One could very easily discover these relationships between interactive choices and correspondent Settings through experimentation and examination of the App Status page.
Application State
Application State are data structures defined by the app/rule during its construction and subsequent execution. These have various uses within the app, and are essentially the equivalent of variables used in a conventional computer program. Without knowledge of the internal code of an app/rule, these are unlikely to offer much insight to the workings of the app. Although, some users do figure out certain correlations between state and app behavior, and often I will ask for this portion of the App Status page to be posted when trying to sort out an app/rule malfunction.
In the case of RM, three elements of state are core to the execution of the rule. These are 'actionsList', 'actions', and 'eval'. There are coded relationships between elements of these data structures and Settings. The Rule can only be executed with both.
Event Subscriptions
Event Subscriptions show the specifics of each event that would activate an app/rule, giving the source of the event (e.g. a particular device), the specific event being 'looked for', and the name of the handler method of the app to be called when that event occurs. The hub system is responsible for awakening the app when these events occur, by calling the indicated handler method.
Scheduled Jobs
The final type of data that comprise a rule are scheduled jobs created by the app during its construction or execution. These utilize the system scheduler mechanism to again call a method in the app.
Taken together, these four data sections define what an app is and what it does. What you see in the user interface is mere display in terms aligned with a user's expectations based upon their interactive choices, a summation of those selections.
In the case of RM, a set of complex state machines are used to present the UI and to create the corresponding data structures. Some of the aspects of these state machines are visible in the Application State of a rule, although most are ephemeral in nature, and only used as the rule is constructed interactively. This is how the app knows what options to present to the user at each stage of the rule's construction.
It is important to note that every app is driven by events. Either an event subscribed to, or a scheduled job, "fires" the app. In effect, the app is always 'waiting' for its events to fire, and it responds according to its design, hopefully realizing the expectation of its user as to the resulting automation.
It may also help understanding of the app creation process that even during the construction of a rule (or any app), the app renders a page of HTML, and then waits for something to happen. The interaction with a page element by making a selection causes the Setting to be made, and the page to be re-rendered. Settings has to be employed for the app to know what has happened, and Application State employed to know what to do next. For example, pressing a Cancel button will set a state variable that the page logic will respond to in order to transition to the next user interface presentation. So, even the construction of a rule is an event driven system, where the events are user selections. As such, an app is a very dynamic piece of software.
6 Likes
These are implementation details that regular users like me wouldn't know, but from what we can see, I would guess that apps and drivers are Groovy scripts that get compiled (to Java bytecode) when the "Save" button is clicked--so basically any time you add or modify code--then executed via the typical methods any time they are "woken up" (apps and drivers on Hubitat aren't always "running"--they execute in response to something, like a schedule, device event, or other subscription). It's possible something else may happen on first execution, hub reboot, or other factors, but I'd consider those details we don't need to be concerned with.
Most of the platform, from what we know, is written in Groovy and Java (as are all built-in apps and drivers, though some of these do have more access to things outside the sandbox than user code would). So, user code isn't anything special in this regard--not like the JVM needs to start up just to run it.
Thank you very much!
This is very informative post for me.
Thank you for the advice.
But my preference for the HA is to use just a single hub.
Also i am desperately trying to bypass all these Clouds, Tornados, etc.
The current version of Rule is about 8,000 lines of code. Of this, only about 1/4 of the code has to do with rule execution, and 3/4 with user interface, i.e., rule construction. The code that actually runs when a rule is triggered is a fairly small amount of code, whereas the amount of code that runs to create an IF-THEN conditional action is fairly large.
2 Likes
@vitaliy_kh Did you see this other thread about a community State Machine app. I don't know anything about it nor have used it but it might get you going in right direction?
2 Likes
Yes, just checked a related video.
Looks good but my idea is very different.
