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

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

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.


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

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

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

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

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.

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.

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

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.

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

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.

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

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.

No errors. This worked well

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.

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

OK, great. I will try this tonight.

I noticed that BigTalker is generating it’s own TTS files. Is it possible to tell when BigTalker has generated new ones? I haven’t got into the code that much, it’s large. There are 3-new devices causing errors due to the Amazon account outtage. If I could get a notification, I could run around the house and press all the buttons to generate new files.

Also, it appears LANnouncer is no longer compatible? I don’t see it in my device list and it is operating properly.

Awesome! I hope that 1.1.8a4 handles the evt.deviceName error for you and properly converts to evt.device.deviceName or evt.device.name on the fly as needed.

BigTalker relies on the SmartThings platform to generate the sound files that are used in musicPlayer mode (Sonos Support, VLCThing, etc). I currently have no way to know if a new file has been generated or if the SmartThings platform is using cached content.

LANNouncer is supported. I use it daily (albeit a personal version that I created to run on my Windows tablet, using the same API calls that LANNouncer uses for speech and alarms; This version isn’t for distribution though as I still have much work to do on it if I were to ever release it, including getting a code signing certificate, convert it to a Windows Service, etc. The Android version will always be easier for the end-user, this one was just a hobby to see if I could mimic it). LANNouncer is a speechSynthesis device and therefore it will only show up when the app is running in speechSynthesis mode. Either musicPlayer or speechSynthesis mode is selected upon install and this tells the app which devices to display as speech devices. I hope to support both within the same app in the next major release 2.0.

1 Like

@adamoutler Did you ever get a chance to try 1.1.8a4 mentioned above? Did it resolve the issue that you previously experienced with %devicename%?

1 Like

Sorry, it’s been hectic with a virtual network I’ve been setting up. I will try to do this tomorrow. Setting a reminder.

No big deal, just hoping for feedback that’s all. Whenever you have time to check.

1 Like

I added the code, then I attempted to Talk Now with %devicename2%

Now I can’t talk now.