Using CONDITIONS within ACTIONS, for automation script

[stickyrice]

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

[John-A]

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.

J.

[stickyrice]

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

[John-A]

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!

J.

[stickyrice]

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

[John-A]

@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.

[stickyrice]

---

@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

[stickyrice]

---

@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

[John-A]

@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.

[stickyrice]

@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

[John-A]

@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.

[stickyrice]

---

@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

[John-A]

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

[stickyrice]

Hi @John-A ,

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

stickyrice

[John-A]

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. 

[stickyrice]

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

[John-A]

@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?

[John-A]

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.  

[stickyrice]

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

[stickyrice]

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:

1. Do you know if IFTTT support any virtual switch?
2. 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

[John-A]

Hi @stickyrice I'll be interested to know if this works for you reliably. I think it's working here but I need more reliable results from the sensor to get any value from it.

I have no experience of IFTTT so I can't advise, other than suggest that the physical switch be used to trigger a virtual switch in another environment if IFTTT doesn't have that feature, then 'flicker' there. Of course that just adds another communication and another potential point of failure so may not help.

If there's a better way I hope you can find it. A conversation with Gemini was helpful to develop ideas for my solution though I had to do some thinking of my own to work up the final algorithm.

Keep in touch.

J.

[stickyrice]

hi @John-A ,

So far so good with the flickering, suppressFor-capture of the google playground virtual switch 👍

On the other hand, for the physical-to-virtual approach, I am afraid the capture (by GHA?) of the physical switch trigger (to start the virutal switch) remains the weakest link.  Yes, very likely just another potential point of failure.  Well, unless .... such capture is more reliable, if done by tuya automation 😂. (note #1 below)

Do you have experience on reliability of trigger capture of tuya physical switch, by tuya automation?

stickyrice

(Note #1: and just yesterday I found the physical switch not captured, again 😔)

[John-A]

Yes @stickyrice I can confirm that within the Tuya environment automation is very (almost 100%) reliable. I have switches triggering other switches, switches that turn themselves off after a specified time, switches that remotely trigger ceiling fans, lights, etc on and off. I originally coded this in GHA but reliability was iffy and time lag was noticeable. Moving the automation into Tuya makes triggers faster and more reliable. I break out of Tuya to Google for things triggered by time, by voice, or by (manually set) presence etc.

The only gripe with Tuya is that if a device disappears from the network long enough for Tuya to remove it from the inventory it has to be manually re-added. Once it's back it remembers it's name but the automations don't recognise it and each automation command it is referenced by has to be deleted and re-added. This is a PITA that I feel sure Tuya could fix.

Cheers, 

John

[John-A]

...and as if to punish me, all of my Tuya Zigbee light switches have just disappeared from Google Home. They all exist in Tuya, and on the Zigbee gateway but not in Google even though I just re-synced. All the other Tuya devices are there but not the light switches. Someone somewhere screwed something up and I'm pretty sure it wasn't me. Because my device to device automation is all in Tuya though that stuff still works. My Google routine that switches some lights on at dusk though did not.

J.

[John-A]

...one further update @stickyrice (because I need someone to hear my pain, that's all) The switches all magically returned but under 'Linked to you' i.e. as new devices without any home or room assigned, so GHA automations still assumed them to be missing. I patiently updated them all (a dozen or so) yesterday evening only to find them all gone again this morning. Maybe when we get the Gemini assistant I can assign them to the job of renaming everything when it's screwed-up.

As of now, they're all missing.

In home automation no one can hear you scream.

J.

[stickyrice]

oh yes @John-A GHA won't recognize the devices that are just "linked to you".  You have to assign them to certain room before that are available for automation (code/script).

Why were they gone, all of a sudden?

stickyrice

[John-A]

@stickyrice I don't know. Maybe an api changed somewhere and made things unstable, or maybe in China some cloud server had a hiccup. Nothing changed afaik at the Tuya side but the symptoms suggest that one manufacturer's devices disappeared from Tuya long enough for Google to delete them, then were reinstated on Tuya with all their configuration unchanged.

The upshot is that I'm doing my best to push GHA automations I've written before on to Tuya so they are not reliant on communication and consistency between the platforms.  Tuya has good time related triggers (including sunrise/sunset + or - # minutes) and for triggers and conditions like 'the TV is on' that Tuya can't see I may try virtual bulbs/switches as a proxy.

It really is all a bit flaky though and I don't want to waste the time remaining before WW3 starts just farting around with light switches and code!