Lot’s of good feedback here. Some possible, some maybe, some not.
BTW, I welcome any ST developer to review the code structure and with that in mind build commented functions or assist in building commented functions for desired features.
I’m investigating moving away from the 3 groups per device type (switch, contact, motion, etc) and move to a parent/child app which could open this door.
This may take some thought and deep planning. I’ve had a few ask about adding personality.
I’ll look into this. I’ve not had SmartThings lose the state of my BigTalker installation, but given history with other apps it’s a real possibility. That said moving from 1.1.6 to 1.1.7 shouldn’t lose your triggers. That is a minor move programatically. Check the bottom of this page for the changes from 1.1.6 to 1.1.7.
It’s not in-app, but logging does exist in the IDE (https://graph.api.smartthings.com/ide/logs). If you desire more than you see, you can enable debug logging within the SmartThings BigTalker app at the bottom of the “Configure Defaults” page. I believe I might be able to show some of the things that I show in the IDE logs in-app. I’ll investigate bringing important logs in-app.
I could see adding some user customized tokens/variables that you could call up in Talk Now as well as within event triggers.
I’ve had adding playing an online mp3 as part of BigTalker at the back of my mind for a while. It’s still there, not a top priority, but a possibility.
I have actually had a function in the code for a while now to remind me to build a queue system. I’ve not done it because I think the queue could get pretty backed up and things could get weird while it flushes the queue. I’ll revisit.
This might help with my queue concern; although it could cause events to not occur that users are expecting and then they think BT is broken. ST docs discourage timers less than 60 seconds, so that could be a really long time and a lot of missed events for some.
I think the unlimited event config via parent/child app design should really help with this.
That’s really what I built Talk Now for; however I do not see why I couldn’t use the Talk Now function within the config pages so that you can test your phrase while configuring if desired. I’ll look into it.
Good idea.
BigTalker doesn’t have much control over this. If someone knows how I could do this, let me know. BigTalker calls the musicPlayer’s playTextAndResume() function. This is a function in the SmartThings device type handler for the device you are using. All I can do is call the function and hope that the device type handler does what it is supposed to do to stop what’s playing, record the track info, play the speech, restore the track info and resume playing. Device Type Handlers have been a thorn in my side in regards to music resuming since the inception of BigTalker. Just when I think it’s working someone else chimes in that it’s not or not consistently for them. I’ve fought this battle for a while and I’m not sure I can do anything else within BT to make it more consistent. I do plan to add a resume toggle switch per event so that resume can be enabled/disabled per event trigger at the users will.
I’ve had some requests to play a beep tone or something prior to playing a message.
This is problematic. BigTalker supports both speechSynthesis device handlers and musicPlayer device handlers. The speechSynthesis device handlers can typically only receive text where they convert that to audible speech. Sending a pre/post tone to these would be impossible. The musicPlayer device handlers could likely do this; however I am afraid it would likely break the ability to resume music playing on the device (ie: Mozart playing > BT requests the musicPlayer play the beep tone > BT then requests the musicPlayer plays the speech file for your phrase > The musicPlayer receives the request to resume play, but there have now been 2 other sounds played since Mozart was playing; likely the beep sound is what gets resumed). I’m not sure this is implementable in a clean non-hack manner.
I am going to assume that you are using BigTalker in musicPlayer mode with a Sonos or some other musicPlayer device. The issue you are experiencing is due to SmartThings caching the audio responses. When SmartThings recieves a text-to-speech (TTS) request for a new phrase, it processes it and outputs an audio file. That file is then cached and used for future calls of that same phrase. A while back SmartThings used a different TTS service on the backend then their traffic load outgrew the service and they switched. The two services used different voices. SmartThings did not delete the cache that contained the old voices. I’ve asked them to here in the forums, their response had hope, but it apparently hasn’t been done. Without hosting and calling out to my own TTS service (which could be large in cost personally to me) I have not control over the voice used. speechSynthesis voices are configured within the device itself. For example LanNouncer uses the configured Android TTS voice, so to change it you could download a TTS voice and then select it on the Android device.