[Released] Rule 4.0

Yes I have been able to consolidate some rules as well although some I appreciate to keep separate. I learned keeping some things separate in simplify was mandatory because there was no good way to cancel a delay in that system ... or at least I never figured out how to do it.

Anyway, sometime separate is easier to keep you sane.

1 Like

@bravenel

Will this work - moving from Rule 3 to 4? The purpose of the rule is not to have the lights turning on/off if the lux hovers around 150. I want a delay (short for getting darker, longer delay for getting brighter)

Rule 3
image

Rule 4 (the 10 second delay is so as to not cancel the newly cancellable delay)
image

I'm having problems with a rule that used to work fine. The problems started with the 2.1.3.120 update. I thought it was just a problem with the cloud endpoints not working, but the problem is continuing with 2.1.3.125.

At bed time, I tell Alexa goodnight. Alexa turns a switch off that triggers the Mode Manager to change the mode to Asleep. That triggers my "everything mode change" rule (RM4). Here's the relevant snip:

Before 2.1.3.125, HE didn't see Alexa throw the switch, so the mode never changed.

Last night, after 2.1.3.125, the rule is getting hung up on the Wait. Even though all 3 of the motion sensors are inactive, it does not move forward and the last two action are never performed.

I changed the rule to add a time out as below. This worked, but only because the timeout triggered.

As I mentioned, this rule was dead solid before. I'm not sure if something changed with the Wait action? If the rule hits a Wait that's already true, shouldn't it continue?

Yes, it should. I will investigate.

I need to see the logs for this. I just tested it with three motion sensors, and it works as expected.

Here's a snip of the log for that rule when it didn't continue. I set "Home" manually, and that's when the rule continued.

And here are snips for the motion sensors at the same time, showing that they were all inactive:

And here's a snip from the rule after I added the timeout and changed the mode back to Asleep, showing that it's the timeout that actually made it continue:

In the top log you show, Wait for Condition, the condition is FALSE. So, after that something has to happen for it to become true, for the Wait to end.

In the bottom one, you have Wait for Events. The same idea would apply here, that something has to actually happen for it to end.

Yes it was false, but you can see from the motion sensor logs that they all did become inactive very shortly after, yet it didn't continue. Same for the bottom one. They were all still inactive because they had never been active since the first snip.

OK, I found what I think is the problem... Investigating further.

Update. Bug confirmed, and fixed. Will be in the next release. This broke Wait for Condition. I'm not seeing a problem with Wait for Events.

3 Likes

Great! Thanks! I’ve changed it to Wait for Condition with a time out, so that should work ok for now.

You guys are awesome.

1 Like

@bravenel, I posted this further up, but it got lost in the mix, and the Rule 4 rule didnt work this morning. Can you please check logic?

Will this work - moving from Rule 3 to 4? The purpose of the rule is not to have the lights turning on/off if the lux hovers around 150. I want a delay (short for getting darker, longer delay for getting brighter)

Rule 3
image

Rule 4 (the 10 second delay is so as to not cancel the newly cancellable delay)
image

You've got to turn on all of the logging and see what happens.

Create a virtual illuminance sensor using Virtual Omni Sensor. The you can test the rule with it by using that instead of the real one you have.

Here is one I have, works great. Uses a high value to turn off and a low value to turn on, this way no ping pinging with a bit of clouds going by....

Just add an End-if at the ...well, the end :grinning:

Rick

Yeah, I was coming to that conclusion. I can see now what the problem was with mine. The Lux sensor reports in every 10 mins. The 10 minute (plus 10 seconds) delay resultsed the newest lux value which was also >150 cancelling the delay from the previous reading, which meant that the GV did NOT change.

Thanks!

10 posts were split to a new topic: Using Rule 4.0 Variables for Time

@bravenel, It seems that it's not possible to use a simple condition with the condition being private boolean of a different rule. I want to set the PB of the other rule, but only if the PB is false. Is that by design?

Edit: cant do it for a IF THEN statement either.

Yes it is. Only a the rule itself can read the state of the private Boolean. Why don’t you use a global variable for that? Global variables can be read and set by any rule.

Even though I am not sure why you want to do it that way. If the PB is true, what is the problem with setting it to true again? It won’t invoke a change...

That's why they are called Private Booleans. They are not accessible for testing in other rules. You can use a Boolean Global Variable instead.

The Wait for Condition bug has been fixed. New hot fix release: Hub Update 2.1.3