Automations in New App June 2021: New features and experiences

The use of automations with the new app 2021 I think deserves a separate thead to point out the new things that can be done and how to do them correctly. Also to comment on experiences about its local operation and others functions.

If someone wants to move to another category or change the title, feel free

I will start with the correct use of the Precondition. When migrating automations from smart lighting I have seen that it has its peculiarities and some do not work as I thought they would.

I have come to the conclusion, I do not know if it is true, that the precondition looks at the state of the device and does not trigger with a state change event as Conditions do. An example:

I want to migrate a smart lighting automation: IF X door is opened and the Z light is off Then the Z light turn on and turn off after 1 minute.

Three ways to do it and only one works well:

  1. With the condition Door X open AND light Z is OFF: It works bad:
  1. With Precondition Door X Open : It works bad:
  1. With Precondition the Light Z off: Works Well

Automation to replace smartApp:

They have already fixed that automations with a closed contact sensor condition for X time to trigger correctly.
Now can be replaced the smartApp “door knocker” with an automation that has the following condition:
IF door is closed x seconds AND door acceleration is active Then Send Notification.
X time in the smartApp is 60 sec.
You can also add other actions, for voice messages, lights, … in addition to sending notification that the smartapp does.

I’m still trying to figure put how to.mobe my front door open/close… light on/off based on door sensor. I cant do that as 1 automation. I would have to do 2, which is not smart.

It is true, if you want to do it as in smart lighting, which starts counting the time to light turns off when the door is closed, it must be done with 2 automations.
@Brad_ST made a list of smart lighting functions that were not in automations. Write only for motion, but for open/Close is the same.
If they are implemented all will be happy.

Now you can use, turn off after x minutes.
That clock starts when the door is opened and there is no way to stop it and it can turn off the light in unexpected cases.

I put in the example as a precondition that the light to be turned on was off. In this way if you have manually turned on the light to do something and someone opens the door, the automation does not trigger and the light will not turn off.

1 Like

Fixed the correct triggering of automations with contact sensors and motion sensors when you use “How long to keep this status” for “Closed” and for “Motion Detected”. For “Open” and “Movement not detected” it was already working fine.

I had an open support ticket done April 26, where they answered me that it was a known bug and they would fix it. Well, it’s already fixed!

Keep in mind that when you use this function “How long to keep this state”, the local execution is lost, as @Automated_House mentioned, in another thread.

Please, could someone from the smartthings team clarify how precondition really works in automations or where to find the information?. @Brad_ST . Thanks in advance

The description of the app for Precondition (translation from Spanish):
“Once this condition has been met, the automatic action will be executed when the other conditions are met.”

With this and with the experience of when it was only applicable to the location mode and the information read in different threads, I had the idea that basically, I don’t know if it’s wrong or true or none:

  • The precondition will not take into account the device status change event.
  • It will only take into account the state of the device, before the other conditions are evaluated.
  • That is, it first evaluates the precondition and then evaluates the conditions only if the precondition is met.

I do not see if it is working like this, two examples of what I see and I do not understand:

1. Automation not working as I expected:

  • Precondition: Door X closed.
  • Condition: Door X acceleration active.
  • Then: Send Notification
  • When the door X is closed and the door is beat (Accel active), it sends notification → OK
  • When door X is opened, acceleration is activated, but does not send notification → OK
  • When the door X is closed, acceleration is activated almost at the same time that the door is closed, it sends notification → NOT OK intermittently. (This seems to work like a normal AND condition.)

2. If I look at the event history of the App, I see the following for the automation:

  • Precondition: “Luz Entrada” is Off
  • Condition: “Puerta Casa” open
  • Then: Turn “Luz Entrada” on

History App:

  • “Luz Entrada” is ON (Precondition is Off)
  • Automation is evaluated when open the “Puerta Casa”
  • THEN part is not executed
  • When evaluating the automation it says: “Automation name” has been Activated

That particular use case is going to be really tricky in a mesh network. Closing the door might itself trigger the acceleration sensor. But you can’t be 100% certain of which sensor report will be received first by the hub because they can and do bounce around the The network. So sometimes you might get the door closed report before you get the vibration report. And other times you might get the vibration report before the door closed report. So I would expect a lot of unpredictability for this.

I would think you would need to put a “has been closed for 30 seconds“ type of precondition rather than “is closed“ to get reliable results, but I don’t know exactly how you set up those automations these days. I don’t have the 2021 app yet.


Indeed, preconditions are not allowed by maintaining a time.

1 Like

Then you might need to daisychain it by having an automation which turns on a virtual switch when the door has been closed for 30 seconds and then having that switch being on be your precondition. But there might be a more elegant way to do it.

That is why I think it is important to know how the precondition is executed, whether it is checked first or not.
if wait for the trigger of any condition to check the precondition.
This is just one example of a critical case, which is not clear how it works.
Fortunately, as the condition with the closed state maintained x time already works well, the automation can be done without the Precondition.

1 Like

I agree with JD. The acceleration/door closing automation seems like an edge case that will have different results depending on how the events are received.

Regarding your first post - Two of the three examples seem to be working as expected. The second example exposes a bug from what I can tell but the first and third examples are functioning as expected.

For the second example, “With Precondition Door X Open”, the precondition does not change the automation from the first example. However like in the first example, the automation should trigger when the door opens. I can file a bug report about this.

@Brad_ST , Thanks for your answer.

I agree, it is a critical case and can be solved in another way.
What I was looking for is try different combinations, to find the most reliable use, especially for when they are going to be used in more important automations, such as STHM arming and disarming, with conditions as the location mode or a virtual switch for delay…

With new functions, more possibilities and flexibility, but more risk of misuse or use with uncertainty windows.

Regarding example 2, with precondition: Door x open, I did not think it was a bug. I thought it worked fine and the automation triggering was done by the condition, not by the precondition, as it seems to be evaluated in the app’s event history.

All clarifications are welcome, thank you

Actually I believe I was confused. Let me check with the automations team but I believe this the expectation:

The first example would trigger under these scenarios -

  • The light is already off and then the door opens
  • The door is already open and then the light turns off

The second example would only trigger under this scenario as the door being open is a precondition -

  • The door is already open and then the light turns off

That’s how I think it is and that’s how it really works.
The Precondition does not trigger the automation evaluation

In case someone is interested, for when you want to debug the behavior of the automations in the event history of the app.
I’ve seen these differences between automation running on local and cloud:

1.With local execution:

  • Is shown in the log as activated even if the THEN part is not executed: When there is a state change in any device that is in the IF part without Precondition or when there is a location mode change with or without precondition.
  • Nothing is shown in the log: When there are only state changes in any device that is as precondition and the THEN part is not executed (It seems that the automation is not evaluated)

2. With cloud execution:

  • It is shown in the log as activated: When the conditions have been met and the THEN part is executed.
  • Nothing is shown in the log: When there are state changes in devices or when there is a change in location mode that are in the IF part, but the THEN part is not executed.
1 Like

Wow. I just noticed this totally annoying logging stuff with ‘Local’ Automations. It’s totally confusing since the Automation is logging when there’s no reason for it. It should only log the Automation when it runs the Action and not just because any Condition is met! This makes troubleshooting Automations much harder since you don’t know if the Automation actually did anything or not, and because it just fills the log with junk when it’s not executing anything.

1 Like

In some cases it can be useful, since you can see which automations triggers each device, but in most cases it makes the history more confusing since the message is the same when the THEN part is executed and when it is not executed.

You can also hide scenes and automations from the history by unchecking General history in the filter


It is certainly confusing, and it sounds like it may be rather inconsistent. As ever we have not been told what it is supposed to mean. Indeed we don’t really know exactly what the ‘precondition’ does either. It could be a concept unique to Automations which could be implemented as conditions without subscriptions, but it may also be an as yet undocumented phase of Rules execution.

I’d rather expect ‘activation’ to mean the conditions of an Automation have been tested, regardless of the result.

1 Like

In the new Android app there is an error in the automations with quick controls:

  • If you press to see it, a message appears “Do you want to update Smartthings? To edit this automatic action, you have to update smartthings”

  • If you press accept, open play store, but it is already updated and you can only open or uninstall.

  • Solution: You have to delete the automation in the list of automations and recreate the schedule of the quick control on the device.

You can also not use the automation toggle switch to temporarily disable / enable and use the toggle switch on the device itself. This works fine.

Opened ticket in smartthings support-uk