Another basic rule last night failed to log anything or turn off a light... that now means that 4 of my 8 basic rules have failed
Sure glad I didn't delete any of my simple automations, guess I'm going back until HE finds/fixes the issue
I sent some info in to their support e-mail.
Going into the basic rule and pressing Done seems to reset it, but you lose any scheduled jobs for the day.
In my case I could replace the basic rules with simple automation, but I'd need multiple simple ones to accomplish what my basic rules do.
@bravenel Any update on this issue? I don't see anything in the release notes that might have addressed this
My support ticket from 3 weeks ago hasn't been answered other than to say it was moved to dev, guess I'll follow up to that as well
Are you using any WAIT that depends on a specific time of day?
I changed my rules to wait X minutes instead.
I've not had any further issues since making that change.
No not at all, the first basic rule is in the first post, doesn't get any simpler than that
Every basic rule I created since has failed so I disabled all of them for now
My support ticket was turned over to dev and I haven't heard anything since
Support told me if the developers find anything, it will be in the next update, haven't seen anything so far
I decided to try them again and within 48 hours, another basic rule failed to turn off the light
Well some of my basic rules continue to fail, seems like it's ones that have restrictions... ones that are based on motion starting/stopping seem to be good, ones based on say illuminance seem to fail pretty regularly...
@bravenel any progress on this?
I will investigate. It will be next week before I can get back to you... I'm not aware of an issue with this, but that doesn't mean there isn't one.
1 Like
As far as I know, there is no bug with this. I tested something similar yesterday. Please turn on logging, and post the logs for the Basic Rule when it runs and fails to turn off the light.
@bravenel things ran great yesterday and today until 3:15, no log entries after that and the motion that triggers the rule has been triggered many times since then
Let me know if you need anything further
Rick
I have a rule almost identical to this (except without the mode and illuminance restrictions you have) that has been running without issue for quite some time..
Have you checked if/when mode changes or illuminance changes are happening?
@bravenel Is basic rules expected to cancel waits if the state of restrictions changes? (The Basic Rules documentation is not very clear on this and nothing about restrictions mentioned in the wait description.)
See also other similar reports:
Restrictions mean 'don't do anything if Restricted'.
This can create a dilemma when you have something Waiting, for example using motion to turn on lights and inactive to turn off, but the Restriction kicks in before they are turned off. If Restrictions meant something else than 'don't do anything', there would be all sorts of unhappy consequences. So, what that leads to is having to separate turn-on logic from turn-off logic if there is going to be a restriction involved, thus allowing turn-on to be restricted while turn-off to be not restricted. But, that leads to having lots of rules. In the built-in app Motion Lighting this is faced head on by having different ways to stop turning on and stop turning off, all in a single rule. If one tried to do what Motion Lighting does in Rule Machine or Basic Rules, you end up with multiple rules for what Motion Lighting does in a single rule. That's just the way this shakes out.
If I am understanding this correctly, the light turns on when the motion is activated and the light level is below a certain value thus also waiting for motion to stop. If the light level raises above the threshold (no loner restricted) and the motion is triggered, the timer is never set therefore the light will no loner turn off?
Seems to me I now recall this being the same thing I had issues with while playing with motion lighting, pushing me to either create multiple rules or to use RM
Seems to me, the restrictions should be attached to the original trigger event and the rule should finish executing regardless of any restriction changes... but that is just me and as since I am not a developer...
Unfortunately Restrictions for Basic Rules, and Pre-Conditions for RM both behave differently. It would make more sense if they work the same way, as I think that's what people expect from Basic Rules, just simplified RM.. It's really not intuitive that Restriction triggers in middle of rule run and cancels it half way through.
Perhaps to you, but not to someone who is counting on a rule not running when Restricted. Restrictions have existed on the platform for as long as it has been available, and they have always worked this way (and do so in all of the other apps that have Restrictions, such as Simple Automation Rule-1.1). Rule-3.0 and before had Restrictions, and this is how they worked then as well. This is also how Restrictions worked on ST back when that was relevant.
Predicate Conditions were just introduced, and while they can be used as sort of a restriction, it is not the same as these Restrictions. There was some discussion about perhaps Predicate Conditions should work the way Restrictions work, but they don't. If Predicate Conditions were intended to be the same as Restrictions, we would have called them "Restrictions", but we didn't, because they aren't the same thing in more ways than the one you are referencing.
A couple of basic points: Your use case is not everyone else's use case, and while you don't like how they work for your use case, what about those for who they do work correctly? We can't so aren't going to change how Restrictions work in Basic Rule.
@bravenel Thanks for the explanations. Have you considered adding Predicate Conditions to Basic Rules?
Haha, no! Basic Rule is intended for beginners, and Predicate Conditions is an advanced feature for Rule Machine, intended for more advanced users. You could certainly solve your particular problem by using Rule 5.0 with a Predicate Condition! RM is not hard, it just has a zillion options and possibilities.
For yours, the trigger is Master Closet motion active; Actions are turn on Master Closet lights, Wait for Closet Motion inactive, Wait for Elapsed time 2:00, Master Closet Off; all with a Predicate Condition of your Restriction.
1 Like
