See pics I did confirm the system is in home mode and as I understand the automation it should not continue to fire?
Does your “Good Morning Hancock” scene set the location mode to something besides Night?
its not the only issue i have another similiar rule that is only supposed to fire and turn on a light for 3 mintures when there is movement in “night” mode and i confirmed we are in home mode and it is still fireing throughout the day… I have removed those rules for now
The first image in your original post shows a location mode condition in mid-edit with Home currently selected. May I ask what you are intending that to illustrate?
Are you absolutely confident the location mode is being set to Home, and that it isn’t then being set to something else? Only your issues do seem to indicate the location mode is still set to Night.
OK this.is a bug in the automation implementation. When you say check the the mode ie home and use the option to check first it should imply this as an.and. you would never check this first and omplu that the rule would be an or . So when you have multiple other rules and have it selected to allow any on the ( ie any motion sensor is active) it still applies the or to the mode selection and that is why the rule is firing multiple times.
Your screen shot shows “At least one condition must be met.” That’s an Or.
There is an option when you create an automation for “all conditions” (And) or “any condition” (Or).
If your automation was created by the migration then, yes, it’s a bug: the default should be And.
If you created it yourself or changed it in editing, Just choose the other option.
yes but reread the description it makes no sense. .when you put a rule in with the mode ie home it should always be an and implied… there is no reason to check the mode and especially if you check to enforce it first… and then use it in an or with other rules.
other wise for my example ith motion on any of the sensors and a certain mode you have have to write x rules where x= the numver of sensors… I am pretty sure when they added the option to enforce check first for the mode they meant to use it as an AND
As the old saying goes, “your use case is not my use case.“ LOL!
Some people have special modes like “guest mode” or “party mode” or “Dogwalker mode” Which they might well want to include in an or statement.
It should always be up to the user how they want to set up the rule.
ok but then why have the option there to make it check the mode first. it is a noop when your rules is “or” . i guess just for performance? also you pick multiple modes at onece in hte location mode and it automatically puts them all in an “ior” in the first rule premise
To be honest, I still don’t really understand how the precondition works. I’m still trying to figure it out.
Also, do you know a way to check which of these run locally as they dont show up in the ide under smartapps… i am trying to keep more local and have moved more over to light manager as i can confirm which run locally.
As a side note the new app is crap in my opion no way to control what comes out on the single tile and all our hard work for layout of tiles in device types is thrown out on the click on opening of the tile… They at least could have preserved those… Getting a hubitat to see if i want to move over, as stability is also important to me with multiple residences and one always being empty
At least i got the performace of the new app bettry. Really stupid of them to have the default view be all the rooms where it has to refresh every device on open. i removed that.
None of the automations using the automation creator currently run locally.
To be fair it actually says ‘At least 1 condition below must be met’. The pre-conditions are above.
Using Automations to effectively replace Routines had long been hampered by the lack of a way of saying ‘only run this automation if the location is in one of these modes’ without the mode change also triggering the automation. There was a clamour to fix this deficiency. So when a location mode ‘precondition’ suddenly arrived unheralded it was natural to hope that ST had delivered on what their users were crying out for.
I created a simple automation saying:
if location mode is night (precondition) -------- if any 1 of the below conditions is met button A is pressed 4 times button B is pressed 4 times then turn light C on
As ‘Location mode will be checked before all other conditions’, it is perfectly reasonable to see the precondition being ANDed with the ‘any’ group. So as the location mode is NOT night I wouldn’t expect pressing a button four times to turn the light on. Yet it does.
In my example, the only way the precondition isn’t a no-op is if the automation gets triggered by e.g. 3 clicks on a button when the location mode is night and the light gets turned on. I haven’t tested it, but I’d find it horribly counter-intuitive.
The presentation of the preconditions is the same whether using ‘all’ or ‘any’. Also when you only have one condition there isn’t even a visual indication of a precondition and it acts as an AND.
I’m rather hoping it IS a bug.
Thanks— I’m still very confused. As you say, hopefully it’s just a bug.
maybe you should report it as your example succintly described the issue. I did file a report but your description is much better.
I find it amazing that I am the first to find this “Bug”. I just got my first site conversion option a few days ago, but this stuff has been out a long while. Makes me unfortunately think the don’t think it is a bug.
But as I said “Precondition” implies an AND.
and it is pretty common to have a rule like i had…
ie if the mode is night and there is motion on any sensor in the morning change to home. etc. etc. It should replace the “things start happening” option that was in the old system
The precondition option is very new, just a couple of weeks. I don’t know how many people are using it.
ah ok that explains it… will see if support can even understand the issue or just tell me to remove and reinstall the app… lol