topic Re: Using CONDITIONS within ACTIONS, for automation script in Home Automation

Using CONDITIONS within ACTIONS, for automation script

stickyrice — Fri, 06 Feb 2026 01:43:38 GMT

I understand that with automation scripts, CONDITIONS can be used only for STARTERS.

Question is: can I do something similar within ACTIONS? Something like "if CONDITION then perform an ACTION".

My situation is within ACTIONS, after finishing action1, I wait for 15 minutes, and if certain device is still ON, then I'll do action2. Otherwise I'll do action3.

Any thoughts appreciated.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Sat, 07 Feb 2026 19:43:32 GMT

Although it isn't possible to code this directly, you can break the problem down and solve it a bit at a time. The script language, based on YAML, is declarative, that is it only solves problems in the form of 'if this occurs, do a bunch of stuff'.

So let's firstly break your problem down into three automations. one that fires 'action1' and then pauses for 15 minutes, another that fires 'action2' then evaluates the ON condition, and a third one for 'action3' that evaluates the OFF condition (in conditions).

All that's missing then is a trigger set by action1 that's the starter for actions 2 and 3.

There isn't any such mechanism inside the automation scripting system, but you can solve this using Google Home Playground (https://home-playground.withgoogle.com/). A switch device created in Google Home Playground can be added to your Home devices, and now you've a binary variable you can switch on and off in a script. Your action1 switches this on, and actions 2 and 3 use it as a starter, then switch it off.

I'm not sure if this works if you trigger it a second or subsequent time while the 15 minute delay is running, i.e. if there's more than one instance of the script in progress. You'd need to test this.

As an alternative to Google Playground you can add a similar fake switch in the web interface for Samsung Smart Things, or use a real physical switch/relay/other device that's not being used for anything else.

Google Playground or Smart Things need to be added as 'works with Google' services inside the Google Home app to make their devices visible in Google Home.

Problem solved (I hope). I've used this method to tackle a number of otherwise intractable workflows.

Hopefully Google Home Playground or something like it will be properly rolled into the Google Home environment someday to make all this easier.

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Sun, 08 Feb 2026 13:03:03 GMT

hi @John-A , thanks for the long and comprehensive reply. I really apprecaite that!

I am happy to hear about your solution --- meaning I am not alone 😀 As a matter of fact, before I started this question, I already implemented exactly what you suggested, using a Google Home Playground switch as the signal to trigger either action 2 or action 3.

Trouble is: Google Home Automation does NOT all the time capture that signal from the Google Home Playground switch. Making my process in limbo.

(but well, if GHA does capture, my logics have been working perfectly)

And hence my question here to see if there are alternative ways of achieving the same thing (ideally, conditionally doing task 1, task 2 and task 3 within a single automation --- per this original question).

Do you experience unreliability with capturing triggers by Googleh Home Automation? Any fixing that you would suggest?

Again, appreciate your feedback here, and I look forward to more hehe 😉

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Sun, 08 Feb 2026 14:32:59 GMT

hi @stickyrice , glad I was a helpful voice in the dark, and your exploration hit on the same solution. I have also found that automations (and start triggers particularly) can be fragile, especially when crossing platforms (Samsung/Tuya/Google Playground) and especially if the triggering event is short-lived.

My only suggestion would be to double up or even treble up. Create your Google Home Playground switch in the Tuya/SmartLife environment and maybe Samsung or some other as well. Set them all, test them all, and reset them all. If only one of them works it doesn't matter if the others don't.

I've also re-designed some of my automations recently to put the automation as close as possible to the device, that is if it only involves Tuya devices build a Tuya Smart Automation and don't write it in Google. This tends to make them more reliable and faster too. I tried this a couple of years ago but Tuya was unreliable and my automations would sometimes just disappear. The whole Home Automation scene then seemed like Windows PCs twenty or thirty years before when everything was a bit buggy, and a Blue Screen Of Death event might lay everything you were doing to waste. Slowly it's getting better but there's a way to go yet.

Keep at it!

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Sun, 08 Feb 2026 23:12:12 GMT

hi @John-A

@John-A wrote:
I have also found that automations (and start triggers particularly) can be fragile, especially when crossing platforms (Samsung/Tuya/Google Playground) and especially if the triggering event is short-lived.

Similar finding here, regarding (small) issue with short-lived triggers. I am feeling that triggers are not populated out real-time, and listening automations are not sampling real-time too. Meaning (a) I need to allow more time for a trigger to "settle" and be updated out around, (b) I also need to assume that listening automation needs at least a few seconds (say 5-10 sec) before it recognizes a trigger.

And then pray for the listening automation to be REALLY WORKING this time.

My only suggestion would be to double up or even treble up.

That's also what I have been doing too 😉

Say, I have found my ARLO geofencing not working all the time. Example: when all family members are away, ARLO may not sense it and switch to another mode. And for such sensing, I find Google Home Automation's sensing much much better. So I also "double up" by also having GHA telling ARLO to switch mode, when GHA senses that geofencing event. Turns out this has been pretty good.

While the above "doubling-up" for ARLO is a good-to-add, I have trouble doubling up my automation around action 1, action 2 and action 3. I hope you don't mind me sharing more details here, but:

Issue 1 (task 1)

GHA-Action 1 is actually triggered by turning-ON of a physical switch, and GHA is sometimes missing the event. I wished I could have avoided the use of the physical switch, since the whole story of this part is just to run GHA-Action 1 every time when any 1 of the geofencing family members returns home (whether there is other family member at home or not) --- but the geofencing of GHA simply cannot do this. As a result, I had no choice but to (stupidly) use IFTTT to turn on physical switch, triggering GHA-Action 1.

So if at least 1 of the following could be improved, that would be great:

having GHA doing the particular geofence sensing, so I can get rid of IFTTT, OR
having GHA capturing the physical switch, more reliably
"doubling up" the workflow from IFTTT to GHA (I can't figure out a way to execute GHA routine directly from IFTTT)

Issue 2 (task 2 and task 3)

GHA-task 2 and GHA-task 3 are conditionally triggered by GHA-task 1, via turning-ON of GH playground switch. As discussed, even this GHA capturing GHA is unreliable.

And I cannot figure out further ways to double this up. Thoughts?

Hope above hasn't been to long/boring for you mate. I do wish to learn more from your experience.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Mon, 09 Feb 2026 20:32:30 GMT

@stickyrice It's a tough one, I've no experience of ARLO and I have avoided using geofencing. I have a virtual switch to signal if we're away for any length of time so that the lights that come on automatically will get switched off again automatically at bedtime rather than manually.

For communication between A1 and A2/3 you could wire a real switch and then set/reset it as the trigger. I tried this as an experiment and it is more reliable than a virtual switch. Google home has occasionally declared my virtual switch to be offline momentarily, even though it doesn't exist!

I will muse on this some more when I get a minute.

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Mon, 09 Feb 2026 21:15:15 GMT

@John-A wrote:
For communication between A1 and A2/3 you could wire a real switch and then set/reset it as the trigger. I tried this as an experiment and it is more reliable than a virtual switch. Google home has occasionally declared my virtual switch to be offline momentarily, even though it doesn't exist!

My experience with physical vs virtual switch is that as a trigger to be captured, physical is no better than virtual. Both can fail over similar chances. Actually I started using physical ones for all signals/triggers, before knowing there was the Playground.

But of course I understand that the ecosystem keeps changing. If you do find GHA capturing events from physical switches better than from virtual ones now, please let me know.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Mon, 09 Feb 2026 21:24:00 GMT

@John-A wrote:
I have avoided using geofencing. I have a virtual switch to signal if we're away for any length of time so that the lights that come on automatically will get switched off again automatically at bedtime rather than manually.

For your situation, I would recommend using GHA's geofencing, which is quite reliable. Add a GHA routine using bedtime as starter, and geofencing status "at home" as condition, for the action of turning on the light.

And of course before you can use GHA geofencing, you have to set up Presence Sensing on all of your family members' devices.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Fri, 13 Feb 2026 16:02:56 GMT

@stickyrice I am trying a 'double-up' test with a virtual Tuya switch and a physical Tuya switch. They are set on by a Tuya automation when a vibration sensor is triggered (Google doesn't read the state of this sensor so it can't be used directly). Both of my Tuya switches are starters for a GHA routine, so either can trigger it.

Results are inconclusive as yet. If triggering happens the delay is fairly long (several seconds) but from time to time nothing happens at all. I will need to add some debug to the script to fathom which switch is triggering and if they are equally unreliable.

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Sat, 14 Feb 2026 09:08:03 GMT

@John-A , it's new to me that there are also virtual Tuya switch!

When you are saying "nothing happens at all", then sounds like both GHA starters for physical and virtual tuya switch are equally unreliable.

The unreliability above is about GHA starters capturing trigger.

Q: How about the tuya virtual switch? Is it equally reliable, in terms of being turned on/off by tuya automation?

If so, at least I can save up my physical tuya switch here (given GHA is equally unreliable in front of tuya physical/virtual switch).

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Sat, 14 Feb 2026 13:10:04 GMT

@stickyrice For Tuya virtual devices you need a free developer account then add as described here https://developer.tuya.com/en/docs/iot/manage-virtual-devices?id=Ka4725tiyfhg0 .

I'm still experimenting and might not have any conclusions until some point next week as (play)time is a bit tight at the moment.

I still have the Tuya routine setting both a physical and a virtual switch, but now two GHA automations, each with a starter triggered by one of the Tuya switches. Each makes a different broadcast to the speaker on my desk so I can tell which one trigered. The result is sometimes one and sometimes the other. Sometimes neither. So far never both.

More work needed to conclude fully, if a conclusion is ever possible.

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Sun, 15 Feb 2026 12:47:54 GMT

@John-A wrote:
The result is sometimes one and sometimes the other. Sometimes neither. So far never both.
More work needed to conclude fully, if a conclusion is ever possible.

hi @John-A , so far never both ....could this meaning GHA only allows one automation running per user every single time? Just to make sure that GHA pooled resources and processing power don't get drained to run 1000s of automations, all under the same user.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Thu, 26 Feb 2026 10:19:18 GMT

Hi again @stickyrice . Some new information. I had a conversation about this automation with Google Gemini. This gave two suggestions

1- Set the virtual trigger in Tuya on for 1 minute before turning it off. I thought that 30 seconds would be plenty but Gemini suggests longer.

2- Make the trigger a virtual light bulb instead of a switch because "Google Home often prioritizes status updates for "Lights" over "Switches" or "Sensors" in its polling hierarchy."

I have no way to know other than testing whether either of these will improve reliability but I thought I'd share in case this would help you too meantime.

It isn't really clear whether the state change is "pushed" or "pulled" in these interactions. Understanding that better would help when it comes to designing a more resillient automation. More research!

Cheers, John-A

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Sat, 28 Feb 2026 04:36:02 GMT

Hi @John-A ,

Thanks for sharing the tips. Have you tried either of these? (I don't have tuya developer environment yet)

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Sat, 28 Feb 2026 19:09:05 GMT

Hey @stickyrice I'm testing both of the these at the moment. I went full belt and braces and send the trigger on/off three times. Three seconds on, wait three seconds, three seconds off, repeat three times. Then make both Tuya and Google wait and reset the trigger after about 30 seconds (not 1min) so I can't get more than one alert every 30 seconds.

Can't paste my Tuya automation, but here's my current GHA code.

metadata:
name: Front Door Vibration Detect
description: If vibration is triggered at the front door, send an alert

automations:
starters:
    - type: device.state.OnOff #The actual vibration sensor isn't readable in Google Home so the virtual bulb is used as a proxy in Smart Life
      state: on
      is: true
      device: Virtual Bulb - ZZ Boolean
      suppressFor: 30sec

actions:

    - type: home.command.Notification
      title: Front Door Knock?
      members: #

    - type: time.delay
      for: 30sec

    - type: device.command.OnOff
      on: false
      devices: Virtual Bulb - ZZ Boolean

The automation is robust now, but my cheap AliExpress sensor is less so. I get some false positives and some missed positives too, but that's a different problem.

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Tue, 03 Mar 2026 00:54:34 GMT

thanks @John-A , that sounds very promising!

Were you toggling this virtual bulb ONLY from the tuya side, WITHOUT touching/waking up any google automation side of app?

The reason behind this question is that I find GHA NOT reliable in capturing starters, even though it DOES the capture successfully, (only) most of the times. I am feeling a "sleeping" GHA (cloud side or device side) the issue, but I have not been able to prove that.

Say, are you able to just switch on this virtual bulb from TUYA side, following a time schedule? that way, you can just touch nothing, and wait for the expected Front Door Knock? notification.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Wed, 04 Mar 2026 16:31:15 GMT

@stickyrice I think this method addresses your concern by giving GHA time to wake and three separate chances to trigger. For clarity here's my Tuya automation.

So the bulb is on 3 seconds and off 3 seconds two times, then on another 20 seconds and off. Meantime if Google detects any of these three times the 'bulb' is on it triggers the notification and also supresses any further triggering of the starter for 30 seconds. The theory is that if GHA 'sleeps' past one of the bulb on states, or the triggering packet is lost in transit it should get triggered by another (or maybe woken by one, and triggered by another). I can't think of any ways to 'know' if GHA is awake but this is maybe like a slap on the face rather than a gentle nudge to the ribs 🐵

Both the Tuya automation and Google finish by resetting the bulb to OFF so double checking that it's ready to fire again after the ~30 second supress.

If I trigger the bulb manually as a test it always seems to fire the notification.

Does that answer your concern?

Re: Using CONDITIONS within ACTIONS, for automation script

John-A — Thu, 05 Mar 2026 07:23:44 GMT

For clarity 'If I trigger the bulb manually as a test it always seems to fire the notification' means I'm triggering the bulb on and off manually in Tuya.

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Fri, 06 Mar 2026 01:16:47 GMT

the use of "suppress" to implement a stronger wake-up sounds good @John-A 👍

I have a GHA routine that turns on on a google playground virtual switch but then GHA itself does not capture such trigger by another GHA routine. 😫

Let me try the "suppress" way to see how it goes.

stickyrice

Re: Using CONDITIONS within ACTIONS, for automation script

stickyrice — Sun, 08 Mar 2026 07:09:29 GMT

hi @John-A ,

I have implemented this "flickering" of google playground virtual switch as trigger, and the capturing of it by GHA, followed by suppressFor. So far so good, I don't see any missed capture which is good news. I'll spend more time to see how reliable this change is. Fingers crossed and thanks!

By the meantime, however, I am still suffering from a similar missed capture, but on a physical switch that is:

turned ON by IFTTT (have to use IFTTT, since GHA does not support triggering on geofencing activity of individual devices, within the same google "home")
captured by GHA as trigger for other actions

Questions:

Do you know if IFTTT support any virtual switch?
If I am to implement similar "flickering" and suppressFor trigger capture over the physical switch, do you know how I could do this flickering, once the physical switch is first turned on from IFTTT side?

Many thanks mate.

stickyrice