Alexa Announcing Nest Doorbell Rings Possible Using Tasker and AutoNotification?

[thexfactor]

This question arises out of @WCmore’s great thread re making announcements and controlling Echos via Tasker and AutoNotification. In that thread, I asked:

I’m trying to use Tasker and Autonotification so that if someone rings my NEST Hello doorbell, the AMAZON Echos in my home will announce and/or chime. While I’m sure everyone know those two devices don’t play nicely together, I feel cautiously optimistic that these two apps can accomplish the following:

1. Someone rings doorbell;
2. Dedicated android phone in basement receives notification;
3. Tasker and/or Autonotification catch that doorbell ring notification (fuzzy on the details here);
4. Tasker triggers a piston in WebCore (fuzzy on the details here, too) that does one of the following two things:
   (i) uses the “playAnnouncement” function on WebCore to alert me someone is at the door; or
   (ii) flips a virtual switch that triggers an Alexa routine that does the same.

Given that WC and ST cannot see the Nest Doorbell (or any other Nest product so far as I’m aware), what’s the best way to accomplish this?

[WCmore]

I am a bit tied up at the moment, but here is the setup:
(please go slow with these steps. It is tough to troubleshoot if you miss a step)
If you have issues, it is better to stop and ask instead of pushing onwards.

---

OK, let’s start off in webCoRE:

Make a new TEST piston, with only a single basic command for confirmation.
(Turn light red or whatever). This is so we can easily test, and see instant results.

A good habit would be to press Test after saving to make sure the command works as intended.

Once the piston is saved, copy the External URL up top, and reset your light back to normal white.

Feel free to use this for your test piston… It automatically resets itself after each test.

---

Most of the real programming is done on your Android.

1. Ring doorbell
2. Leave the notification untouched on the Android
3. Open Tasker on that device
4. In the Profiles tab, click on the (+)
5. Choose Event
6. Choose Plugin > AutoNotification > Intercept
7. Click the pencil icon to edit
8. Click on “Fill from current”
9. Click on Notification (top line)
10. Choose the Nest Doorbell Notification
11. Put a check mark next to
    {i} Notification App
    (ii) Package Name
    (iii) Notification Title
    (iv) Notification Text
12. Click the checkmark at the very top
13. Action Type: Created
14. Apps… Put a checkmark next to the Nest app
15. App Name Filter… Notification App… Verify… Back once
16. Package Name Filter… Package Name… Verify… Back once
17. Title Filter… Notification Title… Verify… Back once
18. Text Filter… Notification Text… Verify… Back once
19. Click the checkmark at the very top… and then go back once
20. In the popup window, choose “New Task +”
21. Click on (+) > Net > HTTP Get
22. Server: Port is the URL on your clipboard. (the rest stays blank)
23. Back up once
24. Click on (+) > Task > Stop
25. Slowly press Back a dozen times to return to desktop (and save your work)

---

OK, now we’ve done with the tricky part…

Manually clear the Nest notification… Wait a couple of seconds… and press the doorbell again.

You should see your light flash red a moment later.

[thexfactor]

Thanks so much! I’ll give this a whirl and report back.

[WCmore]

If you test more than once, each time may require a manual clear of the Nest notification… Wait a couple of seconds… and press the doorbell again.

Later on, once the basic logic is working, you can program Tasker to auto-clear the old Notifications, but during this testing phase, you will have to do it manually between tests.

[thexfactor]

So I now have had a few minutes to play around with this. Thanks for the detailed instructions. First my setup:

1. I created a simulated contact sensor (“SCS”) in IDE.
2. I created a routine in Alexa that plays a doorbell sound on all Echos when the SCS is opened.
3. I tested the routine in Alexa and it worked (doorbell sound plays on all Echos).
4. I created a test piston in WC that opens the SCS, waits 10 seconds, and then closes the SCS.
5. I tested the piston in WC (by testing “Test”) and it worked (doorbell sound plays on all Echos).
6. I tested the piston in WC (by executing the external URL) and it also worked (doorbell sound plays on all Echos).
7. I created the tasker profile, following steps 1-25.
8. I then tested the entire setup and… thud.
9. To make sure I followed all steps correctly, I deleted everything the profile and then did all 25 steps a second time.
10. I then tested the entire setup and… still no dice.

So, it seems the issue is somewhere in the tasker setup. What’s best way to proceed? A slew of screenshots of my Tasker profile?

Thanks!

[thexfactor]

Here’s a copy of my Tasker config:

[WCmore]

7. I created the tasker profile, following steps 1-25.
8. I then tested the entire setup and… thud.

The tricky steps (4-22) you glossed over… So I have a few questions to help narrow it down:

(1) Did you clear all notifications on the Android before pushing the doorbell?

(2) If so, did the new notification come in to the Android when you pushed the doorbell?

(3) If so, can you open the Tasker Task (right side) and press the ► at the bottom to test the Task portion of your code. This should execute the piston that you pointed to in the HTTP GET request. If this portion works, then your issue is in the Profile Tab (left side). If it fails, then you have issues in the Task Tab (right side).

---

Note: There is a steep learning curve with Tasker, and I usually program this for clients due to the complexities.

[thexfactor]

1. Yep.
2. Yep.
3. When pressing the ► at the bottom, the doorbell sounds correctly.

So it seems the problem is with the profile side. The config was uploaded above.

[WCmore]

When pressing the ► at the bottom, the doorbell sounds correctly.

When you say “the doorbell sounds correctly”, do you mean the piston successfully ran, which made a sound effect on the Echos?

If your answer is “yes”, then the Task side of Tasker is spot on.
Your troubleshooting should be on the Profile trigger (left side)

---

Can you confirm that your Nest notification matches this EXACTLY:

A single misplaced character will break this trigger.

[thexfactor]

Yes, the piston ran correctly which plays the sound effect on the Echos. Task side appears to be working fine.

This is what the notification looks like, which seems to match that:

[WCmore]

Hmmm… From a distance, your Config looks good…

I wonder if the bullet is causing issues. Maybe change Tasker Profile trigger to:
Notification Title: Doorbell
and then make sure to NOT match exactly.
(the check box down below should be UNchecked)

---

The other thought that comes to mind is:

During step 14 above, was there more than ONE Nest app to choose from?
(If so, I would check both of them)

[thexfactor]

I wonder if the bullet is causing issues. Maybe change Tasker Profile trigger to:
Notification Title: Doorbell
and then make sure to NOT match exactly.
(the check box down below should be UNchecked)

Well, there is an average 6-7 second lag between button being depressed and the sound on Echos, but that did it! Thanks!

I wonder if I scrap the simulated sensor idea and instead simply have WC announce the visitor, e.g., “Someone is at your front door,” if the speed will be quicker. Right now, the Alexa routine (triggered by the sensor opening) plays a Doorbell track from Spotify all on all Echos which I think slows down the whole thing. To me, speed of notification > having an actual doorbell tone, so I’ll give it a whirl.

8/5/2020, 5:28:18 PM +186ms
+1ms ╔Received event [My home].time = 1596662899147 with a delay of -961ms
+88ms ║Runtime (35795 bytes) successfully initialized in 42ms (v0.3.110.20191009) (86ms)
+89ms ║╔Execution stage started
+348ms ║║Executed [VD - Doorbell].close (250ms)
+350ms ║╚Execution stage complete. (262ms)
+351ms ╚Event processed successfully (351ms)

[WCmore]

there is an average 6-7 second lag between button being depressed and the sound on Echos

This is not normal. A few factors come into play here.

• How long it takes Nest to push a notification to the device (unsure on this)
• How long it takes Tasker to intercept & send HTTP GET (this portion takes about 1 second)
• How long it takes the piston to run (should be less than a half sec)
• How long it takes for Alexa to detect a change and alert us

I suspect the slow-pokes are the first and last from this list.

To help speed it up, I would begin your stop watch when the notification comes into the Android… Not when you press the doorbell. (since there is likely no way to speed up that first step, other than rebooting the Android, and closing un-needed apps)

If this were my project, I would:

• Drop the SimContact
• Delete the Alexa Routine
• Remove any logic checks from Alexa,
• Pipe the voice alert directly from the webCoRE piston.

---

For comparison, I can push a piston’s Test button, it goes to my Android > Tasker, and then executes the same piston via external URL. It can usually make the entire round trip in about 1.5 secs.

(this is going from webCoRE > ST notification > Tasker > HTTP GET > webCoRE)

For reference, my worst test was about 2.5 secs, but I had a lot of network chatter at the time.

[thexfactor]

This is not normal. A few factors come into play here.

• How long it takes Nest to push a notification to the device (unsure on this)
• How long it takes Tasker to intercept & send HTTP GET (this portion takes about 1 second)
• How long it takes the piston to run (should be less than a half sec)
• How long it takes for Alexa to detect a change and alert us

Thanks for your continued A++ assistance. Truly astounding.

In any event, the first step is nearly instantaneous from my tests, so based on your comment I think the time hog is step four.

If this were my project, I would:

• Use a SimSwitch (not a SimContact) ,
• Delete the Alexa Routine
• Remove any logic checks from Alexa,
• Pipe the voice alert directly from the webCoRE piston.

. . . . .

Edit:

Upon further reflection, the SimSwitch is likely not needed either.

Yeah, I think I’ll avoid the sim sensor entirely (sim switches, as an aside, are not supported by Alexa anyway), skip the routine, and just use the “playAnnouncement” function on WebCore to state: “Someone is at your front door” instead.

I’ll let you know how it goes.

[WCmore]

Sounds good. I just did a recent test from
webCoRE > SmartThings > Android > Tasker > HTTP GET > webCoRE
and the results are even faster now. (avg 1.27 sec round trip)

---

Pro Tip:

You can add a short sound effect to the Tasker Task, so the Android will make a tiny noise when Tasker takes over. I use: Play Ringtone > Type: Notification… and then pick the shortest sound available. (I would insert it right after the HTTP GET)

This lets you hear the moment Tasker does it’s magic, and helps to determine which step is taking the longest.

(an added perk is, whenever I hear the chime, I know to “shut up and listen”, because there is a voice alert about to come in, LOL)

[thexfactor]

Update –

First attempt:

Scrapped the sim sensor and avoided Alexa routines entirely. I then created the following piston:

Good news: The Echos responded much more quickly – in approx 2.5 seconds.
Bad news: The announcement across the selected Echos were out of sync with one another. In other words, the first Echo would trigger at 2.5 seconds and the final one may not have announced until approx 6 seconds. (I tried changing the first part of the piston to async, which made it slightly better, but still not perfect)

I think the issue with this piston/setup is that it directs each individual Echo to make an announcement, and no matter how quickly it does that, it will result in some disparity.

Second Attempt:

I created a new piston and switched the WC function to “playAnnouncementAll.”

I selected any Echo, but this function apparently utilizes Alexa’s announce everywhere function.

Good news: All Echos responded in under 2 seconds and in unison.
Bad news: I can’t select this announcement NOT to play in certain rooms (but that is a small price to pay for the speed and sync).

The only remaining issue is this and it’s bizarre (at least to me):

When testing Piston 2 from (i) WC, (ii) external URL, and (iii) the right side of Tasker, everything works great. However, I think there has to be something wrong with the left side now because when I press the doorbell it seems to execute the piston twice. In other words, if I trigger the piston from (i) WC, (ii) external URL, and (iii) the right side of Tasker, the announcement will be made once. However, when I press the doorbell, I hear this:

Someone is at your front door. I repeat, someone is at your front door.
[couple seconds later]
Someone is at your front door. I repeat, someone is at your front door.

I haven’t touched the profile tab since we adjusted for the bullet. But with my my troubleshooting cap on, it seems the issue has to be with the profile tab.

[WCmore]

Good news: All Echos responded in under 2 seconds and in unison

Excellent news!!

---

when I press the doorbell it seems to execute the piston twice

Can you please Clear your logs, set the level to Full, and press your doorbell again?
I’d like to see the double execution from webCoRE’s perspective.

[thexfactor]

Below is one example of many from today. It seems the piston is being triggered twice. At first, I thought it was because Tasker on my Android device is not yet set to auto clear doorbell notifications, but even when I manually clear them, the piston fires twice.

What makes this even more bizarre – and what explains my delay in responding – is that after I posted a week ago, the problem went away. No piston double-firing, no double announcements. Now issue is back and I haven’t made any changes.

(Alas, now that EchoSpeaks appears to be sunsetting next month, any fix that may be implemented may be short lived, sigh…)

8/13/2020, 9:41:09 AM +720ms
+1ms ╔Received event [My home].execute = XX.XX.XX.XX with a delay of 54ms
+93ms ║RunTime Analysis CS > 19ms > PS > 44ms > PE > 30ms > CE
+95ms ║Runtime (36102 bytes) successfully initialized in 44ms (v0.3.110.20191009) (94ms)
+96ms ║╔Execution stage started
+100ms ║║Cancelling statement #1’s schedules…
+339ms ║║Executed physical command [Random Echo Device].playAnnouncementAll([Someone has rung the doorbell. I repeat, someone is at the front door.]) (232ms)
+340ms ║║Executed [Random Echo Device].playAnnouncementAll (234ms)
+342ms ║╚Execution stage complete. (247ms)
+343ms ╚Event processed successfully (343ms)

8/13/2020, 9:41:07 AM +730ms
+0ms ╔Received event [My home].execute = XX.XX.XX.XX with a delay of 71ms
+93ms ║RunTime Analysis CS > 19ms > PS > 45ms > PE > 29ms > CE
+95ms ║Runtime (36102 bytes) successfully initialized in 45ms (v0.3.110.20191009) (94ms)
+96ms ║╔Execution stage started
+100ms ║║Cancelling statement #1’s schedules…
+355ms ║║Executed physical command [Random Echo Device].playAnnouncementAll([Someone has rung the doorbell. I repeat, someone is at the front door.]) (249ms)
+356ms ║║Executed [Random Echo Device].playAnnouncementAll (251ms)
+358ms ║╚Execution stage complete. (261ms)
+359ms ╚Event processed successfully (358ms)

[WCmore]

From this snippet:

8/13/2020, 9:41:09 AM
╔Received event [My home].execute = XX.XX.XX.XX

8/13/2020, 9:41:07 AM
╔Received event [My home].execute = XX.XX.XX.XX

… it looks like the trigger fired twice.
(some buttons are a bit ‘loose’ so a single press may register as two)

---

For a humorous anecdote, consider your previous post:

Someone is at your front door. I repeat, someone is at your front door.
[couple seconds later]
Someone is at your front door. I repeat, someone is at your front door.

If your doorbell button is ‘loose’, then you could go the lazy route and make it:

Someone is at your front door.
[couple seconds later]
Someone is at your front door.

---

Perfect example of making lemonade out of lemons…

[thexfactor]

(some buttons are a bit ‘loose’ so a single press may register as two)

That may be… however, in this setup (with Tasker monitoring notifications), the button press isn’t relevant so much as whether there are two notifications – and there aren’t. When I press the doorbell, a single Nest notification comes up. It baffles me why the piston would trigger twice in this scenario.

Perfect example of making lemonade out of lemons