I suppose I could do a loop but that just seems clunky and I'm also worried about writing too many loops - I read that polling can make the hub unreliable and I'm not sure how much I can push it.
Secondly, RM4 is really frustrating for me. I don't feel that anyone but programmers can understand it, and, as a programmer, it's infuriating to click ten times per line. Also, it has bugs and can get "stuck", rendering the rule broken and you have to start over. I also have come to realize the highlighted values are kind of like debug values, but initially they are really confusing. I'd personally like to see them hidden unless you hit a debug button or 'last run values' button or something.
Secondly, I understand the business case for a UI, but at least give us an advanced place where we can just paste code - web assembly has given us the ability to natively run code in the browser with intellisense, highlighting, compiler errors etc. E.g.: https://groovyconsole.appspot.com/ or https://try.dot.net/. If you just ran your compiler on the client side I don't see many downsides, though I'm sure it's not a day-long project since I'm guessing if any bad code got run it has the potential to break the hub.
It would be great if one of the new requests could be writing actual code - it would also be wonderful for sharing/pasting (as long as you had errors a fairly decent UI - I'm sure no one would have the same devices).
First, if you're comfortable programming, you may want to do just that: the "Apps Code" section under "Advanced" lets you write custom automations as more or less a special kind of Groovy script. (The "special" thing is that Hubitat's environment is a sandbox that both restricts certain features but also provides Hubitat-specific things on top. Documentation is unfortunately sparse, but the classic SmartThings SmartApp development docs are a good place to start, and you can find lots of threads here asking similar questions--and lots of community apps, most with open licenses that you can use as starting points if needed.)
Back to Rule Machine, its purpose is basically to let you write custom automations without having to write custom code. People have asked for a "code view" before, but the response has been that it is not possible--RM doesn't really write code, either, though it displays your actions in a sort of pseudo-code. It's just a regular app under the hood that reads your configured settings and performs your desired actions as configured. They are aware that the UI is awkward, but they're working within the constraints of a model they didn't entirely create (that of ST, which they presumably did do ease porting both their own and community apps--RM originated on ST). But you can write code, just not in Rule Machine.
As for your rule, what is "skipping"? I don't see a description of the specific problem. I can make some guesses: is "Dryer" an acceleration sensor that repeatedly switches between active and inactive? Any time a trigger event matches, your actions will run (from the beginning). Your notification action is getting skipped because the conditional in which it is encased is false, so if that's the problem, then that is why. Presumably you have another way to set activeEndTime?
Hey @bertabcd1234 - thanks a bunch for the info! It's great to know I can just write code - I had no idea.
As far as my RM code - you aren't quite right. I guess I am making some bad assumptions, but I thought that if I did a wait it would be just like any async/await programming language where it would release the current running code and come back to it as soon as the event fired that the switch went to inactive.
The acceleration sensor works great - it's active the entire time the dryer is running and only goes to inactive when it's done. I just thought my code would pick up after it went inactive and continue with a continuation token.
I am saying it's skipping because the rest of the RM "code" says "skipping" in the logs. Again, I suppose I am mistaken about my "wait" assumption, but it would also be good to know for sure.
This is exactly what happens. A Wait creates an event subscription(s), and the app exits. When the event fires, it hits that subscription and the app wakes up to continue processing the actions that follow the Wait.
It should be noted that a subsequent trigger of that rule will remove those wait subscriptions, effectively cancelling the wait.
I wonder if just changing the trigger to active as opposed to changed would fix your issue. In the current form you wait for the device to go inactive but that is also a change which triggers the rule again.
I have one more question - when does RM fire? Changed makes sense to me (anytime the state changes), but if I select active, does that rule fire every time an active event comes from the sensor?
The answer technically depends on the driver, but in general, consecutive reports with the same value from the sensor, should any be sent, do not generate events. No events, no trigger. The driver can control this, but it's generally only done when it makes sense to do so (the classic example: for button devices, you do indeed want a "pushed" event any time the device notes one, even if the button number that was pushed is the same as the last button number that was pushed and the pushed attribute value would therefore not be different; attributes are the way by which devices create events). I can't speak to the implementation of Hubitat's built-in ST mutisensor (or whatever device you're using) driver, but my default assumption would be that it wouldn't generate events unless the device reports a changed value.
If you want to account for this regardless, the PB idea above is one way. You could also use PB to track whether this is the first such change within the same rule (but again this is often not necessary). In pseudo-RM, the general structure would be like:
Trigger:Acceleration changed
Actions:
IF (Acceleration active) THEN
IF (Private Boolean True) THEN
Set Private Boolean False
// Do first-time things here since is first time
END-IF
ELSE
Set Private Boolean True
END-IF
(I do use something like the above, but for a power-monitoring rule where I may get multiple events that meet criteria I'm looking for where I only care about being above or below a certain value.)
Is there a way to determine which switch changed in a condition?
I'm trying to write a rule that alternates between two switches, so if ONE turns off, TWO turns on, and vice versus. Ensuring that one of the switches is always on.
When a rule is triggered, the variables "%device%" and "%value%" are set to indicate the device that triggered the rule, and the value of that device at triggering time (which is also saved as the variable "%time%").
For example, I have a rule that triggers when any of my moisture sensors changes; the first line of that rule is
Notify # JWJr (Pushover): '%device% %value% at %time%'
if ONE changed then
TWO = !ONE
else if TWO changed then
ONE = !TWO
Maybe I'm thinking about this wrong, and on second thought this could lead to a loop if the rule can trigger itself.
The goal is to flip a switch's state based on the flip of the sibling switch. So when ONE turns off, TWO turns on, and when TWO turns off, ONE turns on.
