[Released] Rule 4.0

See second rule above.

1 Like

thanks

This is actually the 4.0 equivalent of what you had:

Trigger Events:  Certain Time: 5:30 PM, Certain Time 8:30 PM
Actions:
   IF (Time between 5:30 PM and 8:30 PM) THEN
      On: TP plug
   ELSE
      Off: TP plug
   END-IF
1 Like

Thanks, I was just trying to build up some simple RM4 rules so I can use them as examples when I try and replace my other RM3s - all of my rules are pretty simple like this, but get more complicated when a rule can be triggered or countered by a mode. I tried a bunch of different ways but they just didnt read right to me so I wanted to get a base one from you.
Cheers

Bruce, I will give you even less to "go on".
Please go on doing what you have been, as it is leaping forward at an unfathomable rate. Thanks for the effort, and especially the results!

1 Like

Playing with wait-for-event with elapsed time as a secondary... does anyone know if you can continue evaluating logic after an elapsed-time condition has expired?

Simple example:

  • door opens
  • wait for:
    ---- motion in hallway
    ---- elapsed time: 1 minute
    (if motion in hallway before 1 minute time expires)
    then speak "motion detected"
    (if timer expires with no other condition met)
    then speak "actions canceled"

I'm sure I'm just missing something in the syntax.

edit: whoops, I think the rule dying is a reported bug, but I am still curious if we can logically determine what condition triggered the wait to end.. like case/switch or perform an if-then-else on what device and what value triggered. This is similar to what I was asking for in terms of a normal rule having multiple triggers and having actions be aware of which one/value actually fired. I believe this is in the works for a future release, but not sure if that portion would carry over to wait-for-events.

I've been trying to add an action to wait for a specific time. If I try to make the time between 12:00 midnight and 12:59 AM, the AM/PM defaults to PM and will not let me change it to AM.

I also noticed that when making a trigger for a specific time between midnight and 12:59 AM, the trigger would show PM, but when I saved it, it would revert correctly back to AM.

ETA: @bravenel just wanted to verify you saw this?

yeah @bravenel - sorry. this is doing my head in. I cant even read what you've advised and actually make it, let alone understand it to find where tf the right dropdown is. it's really f'ing confusing man.
Here's where im up to, which is probably wrong.


1 Like

No, there is no way for your rule to know which of multiple things you chose caused something to happen, unless there is a direct giveaway you can test for.

It seems to me that you are misunderstanding how to construct the logic of your rule. Best idea would be to tell us what you want to accomplish, and then we could show you how it's done. In your example, knowing which caused the Wait to be over would not make sense as a way to determine what action to take -- whatever action follows the Wait shouldn't care what caused the Wait to be over. If for your logic it does matter, then you haven't gone about setting the rule up sensibly.

Gotcha, I just wanted to make sure I wasn't missing this capability.

I'll see if I can post an actual example I'm having a problem with. I believe my biggest hurdles so far have been understanding what happens when a rule is re-triggered. For example, is there a way to STOP ACTIONS on the previous iteration of the rule, without impacting the current?

Ideally I would make it so if motion changes, door acceleration changes, or door contact changes, it resets the timer. I'm just having a bit of a hard time on the exact logical behavior of some of these actions, like stop-this-rule.

So far it seems like stop repeating actions will kill off the actions, even if called outside the loop... which confuses me from a programming perspective. I would expect a loop to only 'break,' 'continue,' or complete until a while/for/etc condition is met.

Will stop-repeating-actions and stop-delayed-actions kill off ANY and ALL actions of that nature in the current rule thread, and any prior that might be running temporarily (due to the triggered nature?)

No, a rule has no way to know that it's been re-triggered. It only has one state (memory), so it can't tell multiple instances apart. Stop Actions stops delays, repeats, and the like (it tells you in the UI what it stops). Your Stop Actions is redundant to your Stop Repeating and Cancel Delayed Actions -- and you don't have any Delay with cancel selected, so that does nothing.

Bear in mind that what is happening with both delay and repeat is that the rule instance sets a timer and exits. What Cancel, Stop Repeating, and Stop Actions do is kill the timer. That's why they can happen anywhere. You don't have to do it that way necessarily. For example, you can have a while loop or a counted loop, neither of which use Stop Repeating, or a repeat until loop, which does use Stop Repeating. The limit on a while loop is that it uses a Simple Conditional action, so only has a single condition. You have multiple conditions in your scenario.

It's still not really clear what you're actually trying to do. Could you simply state in English words what you want to happen?

If I understand this correctly, while a rule is executing a new trigger will be ignored?

Not at all. It will trigger again. However, be careful with what you mean by "while a rule is executing". When a rule is delayed, or repeating, or waiting, it is not executing. The time it actually executes is very short.

But your example says "ELSE" not "IF THEN" if im already up to the below section.

Yes, it starts with IF (time...) THEN. So if the time is between 5:30 and 8:30 the next thing that happens is it turns on the TP plug. But, if it's not during that time, ELSE, then it turns off the TP plug. That's exactly what your original rule did.

When it is triggered at 5:30, the IF (time...) THEN will be true. When it is triggered at 8:30, it will be false so those actions following ELSE are run instead of the ones following IF-THEN.

IF (something is true) THEN do some actions, ELSE (it's not true) do some other actions, END-IF.

You know, like this: IF it's raining THEN wear a rain coat ELSE put on sunscreen.

1 Like

I can't find "ELSE" is what im saying.

I understand what you are saying, and reading the rule you have in that box, I can read what its doing. Its trying to MAKE the rule in RM4 that is driving me nuts. I dont know what to click, where to click, once I do IF THEN, time, it takes me back to conditions, then I cant find else, so I try all the dropdowns and nothing says ELSE, then I go back a step to see if I missed it, then it adds the Run without the else...
Then I get the sh*ts, take some screenshots and come back here frustrated.

RM3 took me less than 10 minutes to make this rule.
I know im dumb, 100% willing to admit it. But RM4 is a bridge too far for me. Im super time poor and haven't invested enough time with it, but with HA - I kinda dont want to waste an hour at night trying to code this up. More power to you guys that do, seriously - y'all do amazing things and i stand on your backs and get to experience it a bit.

I just want to write a simple rule, like with RM3, see it work, be happy and go to bed lol.

Hey Steve,

I'm right there with you, RM3 was hard enough, RM4 is another animal.

Bruce has suggested to stick with RM3 if it works for you and in fact, they will continue to work for years to come... His suggestion was to create a Triggered rule with nothing in it, name it RM-Master and in the future, you can just clone it and then create a brand new RM 3 Rule.

Then learn RM4 slowly as you go.

Just a thought
Rick

2 Likes

From what your saying it shouldn't be there, you need to select the IF condition first then select the actions. Then when you go back to conditional actions your see else. Post some shots to be sure.

RM 4 is easier to use once you get the eureka moment, then your be plain sailing. Just keep at it and ask

2 Likes