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.
1 Like
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.
1 Like
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.
2 Likes
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
1 Like
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