Rule machine 4.0 is too hard to use (Part II)

[bertabcd1234]

@dondo

First, providing a single boolean to track state seems arbitrarily limited. People need state. Working around this results in hacks such as people defining a virtual dimmer switch simply to emulate a scalar variable, or using global variables with curated variable names to work around the lack of good variable scoping.

Private Boolean hails from the days when there were no variables at all and this was one way you could "track" something (actually, I think it was also a restriction that would cause the rule to not run if false...been a while). Virtual dimmers and other devices were workarounds some people used before global variables, and it's something you still can do even though they exist now (including booleans and other types), but...

to work around the lack of good variable scoping.

There are local variables now, too. You do not need to worry about careful naming of global variables for the purpose of avoiding confusion in multiple rules. I'm guessing this addresses the "single boolean to track state seems arbitrarily limited" issue.

@dondo

We can read or set another rule's private boolean - which most definitely means it is not private, at least not in the sense that most programming languages use the term. We can fire, pause, or resume another rule, or use another rule's being fired, paused, or resumed as a trigger ourselves. All in all, it seems like a twisty, intertwingled opportunity to accidentally hurt myself all the way down.

There are times when these features are nice to have. I recently suggested one for a use of PB in another thread (and actually, a local variable wouldn't have worked here since those can't be accessed by other rules; but yes, "private" boolean might be a bit of an odd name for something that is, in this sense, public).

In any case, if you don't find a good use for this features, don't use them. (I have never had a good reason to steal another rule's triggers, and only rarely have I had a reason to do anything like the above. I actually had to verify that some of the rest was possible--it is, indeed.)

@dondo

Third, the implementation of delay/pause/wait is tricky and I think needlessly complex. First, the implementation here seems muddled and mixed around with other concerns; we have three primitives that do largely the same thing based on how processing is restarted: "delay" waits for a fixed amount of time; "wait" responds either to an event or sensor data state change; and all can be interrupted by another rule (while "pause" waits only for that explicit interrupt). In the user interface, delay and wait are organized together, but they're somewhat mysteriously mixed in with repeat; meanwhile, pause is mixed in with setting variables and "run rule actions." But all of this suggests an intriguing thought to me: consider that this interaction basically introduces the concept of a trigger in the middle of an operation. Right? Delay is a one-time scheduled event; wait is just sticking a trigger in the middle of the rule; "pause/resume" is a trigger aimed only at that one rule.

I can understand this: triggers for things like "motion changed" or "contact open" create device subscriptions. A "wait for event" or (if not already true) "wait for condition" does the same ad hoc in the middle of the rule actions. These can be nice to simply rules and minimize device subscriptions (not a huge concern but still not something you should do more than really needed to maximize performance). If I recall, the "Wait..." actions are a bit newer. They also do behave differently. Consider the following equivalent ways of writing the same rule:

Trigger: Motion changed

Actions:

IF (Motion active) THEN
  Cancel Delayed Actions
  On: Lights
ELSE
  Delay 0:05:00 (cancelable)
  Off: Lights
END-IF

...or:

Trigger: Motion active

Actions:

Cancel Delayed Actions
On: Lights
Wait for event: Motion inactive
Delay 0:05:00 (cancelable)
Off: Lights

The original (and I think current) Rule 4.0 docs have a lot of examples that look like the former. Staff have lately been suggesting things like the latter to make rules "simpler," though it is not clear to me if that means for the user or for the hub (for the hub, the biggest difference I can see is that the trigger will only happen for one of two events, though mid-rule a second subscription, which I suppose you can think of as a certain ad hoc "trigger" to continue with specific actions, does get created). In both rules you have a "Delay" that creates a scheduled job and causes the rule to wake up again and continue with the remaining actions, as well as a "Cancel Delayed Actions" action that will cancel that delay (which will not get cancelled unless you do this--or go way overboard and "Cancel all timed actions" on this rule from another rule, which is again probably one of those things that would be very rare to need to do) if the rule wakes up in the meantime and happens to be executing a code path where that action would occur. Note that you don't need to explicitly "cancel" the wait in the second rule; any trigger matching will cause any in-progress wait to stop (and no actions after it to run).

The existence of all of these is probably partly a product of how RM has changed over time, but it is worth noting that they all have particular uses that become apparent by seeing more examples and writing more rules.

@dondo

I want to be able to create named triggers

I might be missing something, but I honestly think you can already do this today. Use global variables, then create one or more rules to manipulate those global variables however you want (could be a complicated set of IF THENs in your actions). As you might know, you can trigger rules based on global variables changing or becoming equal to (or other operands, depending on the type) a specific value. Use that as the trigger for your "real" rules.

That being said, I'm not sure I've seen anything like that before, though I think it should work. I second the suggestions above to provide specific examples of automations you want to achieve, and perhaps a seasoned RM user can provide an example that does what you want (or suggest a native or custom app that does the same; I would not turn to RM for all of my automation needs unless it's clear a native app doesn't do what I want and I don't want to use custom code, which there is indeed an element of caution you should be aware of when using).

There's no denying that RM has a bit of an awkward UI and it takes some getting used to. I resisted for a long time but am quite comfortable with it now. I'm sure staff value the comments from "new eyes" who haven't already become used to these oddities, which it's probably hard for longtime users to even identify anymore. I'm just not sure I'd count on drastic RM changes anytime soon.

@dondo

I'm a pretty experienced developer.

It's a bit unlike "normal" development (apps aren't constantly "running," there is a difference between apps and drivers, and the environment is not super-well documented but not terribly different from the also-not-super-well-documented-but-better-documented SmartThings "classic"/Groovy environment; there's more to know than just Groovy), but perhaps you'd enjoy writing custom apps more than using RM. The classic ST developer docs are good start, though a SmartApp would be "Apps Code" (and just an "app") rather than the IDE in Hubitat land.