[(OBSOLETE See 1.1.10 or later) 1.1.8 10/11/16] Big Talker - Talk when events occur

#1

I had to start a new thread (the original aged out for editing)…
Important: For installation instructions and other information or if you have not read it, please see post #1 of the original thread: [OBSOLETE 1.1.6 5/25/16] Big Talker - Talk when events occur

BigTalker RELEASE 1.1.8 10/11/2016: 1.1.8 Release
  • I believe that I have squashed a couple of bugs that may have missed playback or caused playback that wasn’t desired for musicPlayer devices (Sonos, etc).
  • There is a new %description% token that you can use for a description of the event which occurred via device-specific text. Ex: %description% becomes ‘Front door is closed’ (Thanks for the idea STCommunity: adamoutler).
  • The %devicename% token now does error control to find the next best device name rather than crashing the app if the expected call fails. The calls try in the following order: evt.displayName, evt.device.displayName, and finally evt.device.name - One of these will return something; the order is to try to make sure it’s the user defined name. (Thanks STCommunity: adamoutler).
  • Changes default volume applied if in musicPlayer mode and musicPlayer device volume is less than 50% and a desired volume is not configured then device will bump up to 50% to speak and should return to the user configured volume on resume (was originally set to 75% if device was at 50 or below).

Development release 1.1.8a4 has been out for a month with no further issues reported; therefore I am moving it to release as 1.1.8.

BigTalker 2.0 is still in progress for those curious, follow this thread for discussion ( BigTalker 2.0 -- Development )

BigTalker RELEASE 1.1.7 (minor change) 8/22/2016:
1.1.7 Release

  • Added missing %devicechange% reference in in-app “Phrase Tokens” help page. (Thanks ST Community: @adamoutler)
  • Removed Paypal donation link that no longer allows donation without login; just send via regular PayPal or the other methods. (Thanks ST Community: @Gorilla800lbs)
  • Called setAppVersion() sooner in SmartApp execution to show version # more accurately.

Starting with this version release, I’ll begin stamping old version icons with an X over the speaker to let you know in-app that a newer version is available. If you do not wish to upgrade to the newer version, the X stamped version will continue to work.

Get it here: https://github.com/rayzurbock/SmartThings-BigTalker
–Or-- if you have integrated your IDE with GitHub, go into the IDE > My SmartApps > Update from Repo > SmartThings-BigTalker (master), check BigTalker.groovy in the Obsolete window, check Publish, click Execute Update

6 Likes
Fabriq DLNA Airplay bluetooth speaker with Alexa $40
Arm and disarm smart home monitor, play a notification over sonos
ST Disconnects iPad (Spotify) from Sonos
[OBSOLETE 1.1.6 5/25/16] Big Talker - Talk when events occur
[OBSOLETE 1.1.6 5/25/16] Big Talker - Talk when events occur
Does "Speaker Notify with Sound" support dynamic custom message?
#2

Great! Out of curiosity, is Alexa or conversational computing outside the realm of this project?

https://echosim.io/welcome?next=%2F

It might be neat to feed in “switch in office turned off” and get a response back from a natural language processor. I’m really digging the talking house thing, it’s like Eureka!

#3

This is an awesome feature.

2 Likes
#4

Is there any way to add a delay before speech? I’m using DLNA generic renderer and it seems to truncate the message by a few words whenever it starts talking from an extended time of standby. Also, it is possible to trigger a mode change whenever something is spoken?

Thanks for the great work! With the original Speaker Notify with Sound, mode changes could never trigger the speaker.

1 Like
#5

What do you mean? Alexa won’t speak without being prompted verbally. At least not for now…

#6

Never mind, it seems that the delay has to be added to the speaker settings and not the app settings.

#7

Alexa was one example. API.io would be the other. These are audio input and processing devices. This is why I asked.

#8

I’m getting these WARN messages in my logs whenever my configured contact sensors trigger. Big Talker plays the sound fine but I wanted to understand why I’m getting these WARN messages and if they could be contributing to my slight lag (3-4 seconds) before sound is played.

Thanks.

Pasted image956×347 62.6 KB

#9

I may be able to add this as a per-event option. I’ll check into it.

#10

I don’t think that the “warn” messages are from BigTalker but from the Device Handler used for your device. BigTalker users Trace and Debug logs. What is type of contact sensor are you using? Did you have to install the Device Handler via SmartThings IDE or did it natively install from the ST app?

1 Like
#11

I have a few of the GoControl/Linear z-wave contact sensors using the native DTH.

#12

From what I’m seeing searching around:
“command: 2001, payload: FF” = Open
"command: 2001, payload: 00" = Closed
It seems like the device type handler (DTH) that you are using is not properly handling these events.

The only thing I know to try is to change the associated DTH with your device and test again.
graph.api.smartthings.com > My Hubs > Find the device and click on it > Edit > Note the Type (I’m curious what type does it show? I don’t see “GoControl/Linear z-wave contact” as a native option) and change it to a different contact sensor, click update and test.

You could also try installing this custom DTH and use the above steps to select it for your sensor and see if it works better : [RELEASE] GoControl Door/Window Sensor, Motion Sensor, and Siren DTH

1 Like
#13

Thanks the reply.

The DTH is actually just a “Z-Wave Door/Window Sensor” for this device and I’ve never changed it since it was first installed.

Thanks for the pointers, I’ll start from there.

#15

On or around line 2861, please make the following addition to allow for device-defined description messages to be ported into BigTalker.

def processPhraseVariables(phrase, evt){// this was already here
    if (phrase.toLowerCase().contains("%description%")) {phrase = phrase.toLowerCase().replace('%description%', evt.descriptionText)}  //Description of the event which occurred via device-specific text`

on or around line 2865: please change “evt.displayName” to “evt.device.name” for compatibility with V2 boxes. evt.displayName is invalid and crashes the app.

#16

I’ll publish soon (maybe tonight)
with this code, %description% spoke the following phrase when I ran it: Patio Door is closed.

I am using a v2 hub as well and the app is pronouncing as it should without crashing (iOS and Android versions). I’m using evt.displayName as shown in the dev docs (“The user-friendly name of the source of this event. Typically the user-assigned device label”). Is this crash happening with a specific sensor model/type? Have you given that device a custom name ie: back door instead of Z-Wave Contact Sensor, what does the IDE show for the label of this device? see screenshot below.

I tested adding evt.device.name as %devicename2% just to see what it would say and it spoke the name that is shown in the IDE which is not configurable by a user in the App. The docs list this for evt.device.name “The internal name of the Device. Typically assigned by the system and editable only by a user in the IDE.”

  • %devicename% is now %devicechange% spoke the following phrase: patio door is now open
  • %devicename2% is now %devicechange% spoke the following phrase: z-wave door/window sensor is now closed. Patio Door is closed. **This result is not typically desirable

It did for me just what the docs said… evt.displayName spoke what I have labeled the device and evt.device.name spoke the IDE name of the device (found under graph.api.smartthings.com > My Locations > Devices > Patio Door):

Perhaps we can use evt.device.displayName as it speaks the user configured name properly as does evt.displayName for me. I tested adding evt.device.displayName as %devicename3%

  • %devicename3% is now %devicechange% spoke the following phrase: patio door is now open

Can you try replacing evt.displayName or evt.device.name with evt.device.displayName on your end and see if it works crash free for you?

Alpha test code (currently 1.1.8a2 9/8/2016) here: https://raw.githubusercontent.com/rayzurbock/SmartThings-BigTalker/development/smartapps/rayzurbock/big-talker-dev.src/big-talker-dev.groovy
1.1.8a2 development notes:

  • I think I squashed a couple of bugs that may have missed playback or caused playback that wasn’t desired for musicPlayer devices (Sonos, etc).
  • There is a %description% variable that will stay.
  • There is also a %devicename2% and %devicename3% variable for testing that will go away.
1 Like
#17

Unfortunately, while testing, I removed and readded my Big Talker instance. This caused me to lose my oauth token. Now the app keeps saying 403 forbidden.

I removed the app to keep it from buzzing all the phones on my network. I performed the testing above without voice, only using debug output.

I do have custom device names set and I fire ZigBee commands directly at my lights without a proper event name, so maybe that’s it. My event.name is usually something like “battery” or “on/off”. I’m working on the code though. I need to become more compliant with standards apparently…

If you can access the event.device.name, that would likely be the best way to do it. Whenever Amazon comes back up, I will be all over it.

#18

You should be able to just overwrite the BigTalker code without removing and readding. I’m not sure about your oauth token either, BigTalker doesn’t use oauth.

In 1.1.8a2 (test code) that I posted a link to above:

  • %devicename% calls evt.displayName as usual
  • %devicename2% calls evt.device.name
  • %devicename3% calls evt.device.displayName

Try those and see how they do for you.
I’m going to guess from my test results that the majority are going to want the custom label of their device produced by either %devicename% or %devicename3% (%devicename% will be the official token as %devicename2% and %devicename3% will only exist in the Alpha/Beta version(s)). Perhaps I could do some try {} catch {} routines to get the device name and fail over to evt.device.name in case of an error with either of the other two methods. I’ll wait on your results of these commands before proceeding further.

Is this a custom device handler that you are developing that is not returning evt.displayName?

1 Like
#19

No, I mean, My TTS service is completely down right now. Amazon is not allowing new OAUTH tokens currently. I have a record of all of the speech output, but the service is down and not allowing new users to use it. http://status.smartthings.com/

A potential solution would be a centralized database because I can access previous audio without a token, but I cannot generate new TTS audio, and I can’t use Big Talker for any TTS operations because it generates new events and then reuses those events in the future.

#20

I managed to get it working again. So here’s the results:

%devicename%
cebdf3b0-4926-4d4b-859c-11a3cbf31739 12:43:53 PM: error java.lang.NullPointerException @ line 2865
I’m also getting a SmartThings notification that the event could not be sent by bigtalker.

%devicename2%
No errors. This worked well

%devicename3%
No errors. This worked well

It appears the evt.displayName is dependent on the developer of the device setting a displayName on the event itself. This isn’t in the tutorials for creating an event. So, I’d recommend using device.displayName for “%devicename%” and maybe create an alternate “%eventname%” variable for the event displayname.

#21

Thanks for your feedback.
I’ve updated the alpha code to 1.1.8a4 to use only %devicename% (%devicename2% and %devicename3% are gone with this version as they were for testing only) but for the replacement of the token to use a series of try{}catch{} routines to trap errors and try the next best method of retrieving the user configured device name.
If you do not mind, please test with your implementation and let me know how it goes.

1.1.8a4 is located here (Note: only for beta/alpha testers, please)

1 Like

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.