How do you prevent crashes of audio announcements?


(Joel W) #1

I have a few audio automation’s using WebCoRE and two of them crash and garble the text. Example when I open my front door or Laundry room door it announces a text line. I also have an announcement when my SHM sensors the doors opening and starts countdown for entering code on keypad. So when I open either doopr when the alarm is armed the speakers start to talk, and then the regular door announcement starts garbling either announcement. So how do I stop this from happening?


#2

Are all of your announcements coming form WebCore or different smartapps? If they are all coming from WebCore, you could use a global variable. What you would do is that in the piston that is making an announcement you set a global variable like @announcing to TRUE. Then you issue the command for the announcement. Then you add a wait for the expected number of seconds you expect the announcement to take, then set the variable to FALSE. You would then add a restriction to the “do” block that the variable has to be false. Now, of course that means that you would just lose the announcement that isn’t played. Don’t know how important they are. Instead of a text line when your front door opens, have you thought of a bell sound? There’s a smartapp that allows you to play pre-build sounds on one or multiple speakers when an event occurs. So it would just Ding rather than announcing a text line. How important is it that the laundry room door has opened?

Other solutions will also vary greatly on what type of device you are using to broadcast your spoken notifications. Are they VLC “things”, Sonos speakers, Alexa devices?


(Joel W) #3

Ryan, that is a lot to digest. I now have to decide on which way to go. I can also use the mode I guess, so if I am away and come back the first door announcement will not work.


#4

Hmmm, I I wonder, I have sonos play one speaker.

Speak text “blah blah blah”
If [sonos:currentStatus] changes to ‘stopped’

Then
Speak text “second blah blah blah”
Etc.


#5

That would mean you wouldn’t get the second announcement unless it always followed another announcement. Also, you would get the announcement whenever the speaker stopped since that’s a trigger.


#6

I will have to play with it when I have some time. I’m sure with some conditions it would work as needed… time will tell.

However you could have a piston just for playing. They’d send $args to that piston. If ther is no $args it won’t play anything.