Nothing special unless you want it to chime or make other tones instead of talking. I like to use @#ALARM=CHIME for my contacts so it makes a pleasant tone whenever the door opens.
You're not doing anything wrong. Both Big Talker events (Talk Now and the button push) use the same function within Big Talker to speak. SmartThings currently has an issue on the backend with text-to-speech conversion. It has been there for several months now (search the forums for textToSpeech and you will find many complaints/attempted workarounds). It doesn't always come up and usually does with new phrases, but can occur with phrases that have previously been spoken as well. They know about it and are working on it. Lately, it seems to be much smoother for me, but if it's a processing issue it may be regional; they haven't said. In the Big Talker 1.1.4-Beta versions (and soon 1.1.4 release), Big Talker now detects when SmartThings processing is not able to properly convert the text to speech properly using their textToSpeech() function and gives you a visual alert instead. It tries to convert the text to speech twice before giving up and converting the alert to a visual notification. In versions prior to 1.1.4-Beta, the app would just not speak or alert.
Understandably this is causing problems but I thought that LANnouncer is supposed to be doing its own TTS conversion directly on the Android device. Shouldn't this bypass SmartThings backend TTS processing? If that is the case, LANnouncer itself is also having some problems, at least with Big Talker.
@Jimxenus Actually these are pure Big Talker issues. Which isn't really all that surprising; Big Talker is, well, big... there are bound to be some bugs. (I've fixed a handful in LANnouncer too; check out the change list at the Play Store.)
LANnouncer does do its own TTS. From the code (@rayzurbock can correct me if I'm wrong - I'm looking at the
def Talk(phrase, customSpeechDevice, evt) method), Big Talker is using the SmartThings hub TTS when the device is a music player (e.g. Sonos, VLC), requiring about 80 lines of code. But when the device is a "Speech Synthesis" device (as LANdroid is), it's just doing a single line,
You don't, technically, need Big Talker to use LANdroid. But Big Talker makes it really easy to connect events to phrases and to fill in device name, status, etc, that I really didn't see any point in writing my own or to find something else.
I haven't looked at your code until now and I cannot test against it for a couple of more weeks when my Android device can finally update to Lollipop. I incorrectly assumed your deviceType was being exposed to SmartThings with
capability.musicPlayer. BigTalker has quite a bit of logic built into the musicPlayer (Sonos) devicetype to determine if it is currently playing music or not and if we need to resume or restore music based on that status.
capability.speechSynthesis doesn't have this type of functionality which is what LANdroid Alerter deviceType uses. speechSynthesis is very simple without having to worry about resuming/restoring music tracks. It's actually what I built BigTalker on initially before I had a lot of requests for Sonos so I had to find a way to mesh the two. Speech Synthesis deviceTypes are basically just a call to the
speak("desired phrase") function of the deviceType and then the deviceType handles the remaining processing of the phrase from there. The textToSpeech() function that I mentioned in my previous post is irrelevant to speechSynthesis devicetypes and so is much of the other code in BigTalker's Talk() function. The irrelevant code in Big Talker's Talk() function is skipped for speechSythesis devices.
BigTalker parses the tokens in your desired phrase to convert them to device names, etc as desired. It then iterates through your selected speech devices for the event (or the default selected speech device if a custom device is not selected for the event) to determine if each one has capability.musicPlayer or not, if not, then it simply adds a log entry to SmartThings Live Logging showing
sS | speechDeviceName | Sending speak() (sS to show it is sending to a speechSynthesis device) and then it calls
it.speak(phrase) to pass processing on to the deviceType. It does this one at a time for each configured speechDevice in your defaults or custom speechDevice for the fired event.
You can see what phrase is being sent within
it.speak(phrase) using SmartThings Live Logging.(https://graph.api.smartthings.com > Live Logging > BigTalker (after talking).
There is also a debug mode that exposes more data (BigTalker > Configure Defaults > (scroll to the bottom) and turn on Enable debug logging)
Once you attempt to cause Big Talker to speak you should see the following relevant logs:
BIGTALKER(1.1.4-Betaxx) || TALK(event) >> desired spoken phrase here
BIGTALKER(1.1.4-Betaxx) || sS | Speech Device Name | Sending speak().
If the speech device name and "
desired spoken phrase here" logs are correct, then once it sends the speak command, the processing is out of BigTalker's hands. If "
desired spoken phrase here" is not correct or contains unexpected characters (such as the % characters), then BigTalker is somehow not parsing and sending plain text as expected when it calls the speak() command which is likely unexpected by the receiving deviceType. The speak() function in LANdroid Alerter first trim's the desired phrase that it receives from BigTalker (removes prefixed and trailing spaces), then adds the phrase into a URI string which is finally passed on to the Android app using a HubAction. If the phrase contains special URI tokens such as '&' or '%', this might break the URL processing depending on the app/hub parsing/processing. BigTalker parses replaces it's known tokens %weathertoday% with actual text and doesn't pass on the "%" characters. If you use an unknown token such as %unknowntoken% then it will not be replaced and will be sent as-is. Reserved characters in URI's include any of the following characters "; / ? : @ & = + $ ," Another thing to look for is if the speech device name is not correct then there is a bug in Big Talker when iterating your configured default or event speech devices.
Processing goes like this:
1. Big Talker receives an event that is configured to speak on (ie: Front door opens)
2. Big Talker then sends the desired phrase for parsing to see if there are any tokens that need to be replaced and replaces them with their plain text results (ie: %devicename% becomes "Front Door")
3. Big Talker then writes a trace log to Live Logging indicating that it has been triggered by xxx device with xxx event and what the resulting plain text desired phrase is. (ie: Configured phrase "%devicename% is now %devicechange%" should show "Front Door is now open" in Live Logging in this example.)
4. Big Talker then looks to see if you have configured a custom speech device for this event or if it needs to use the default configured speech device
5. Big Talker then starts to iterate through your configured speech devices for this event
6. Big Talker determines if the current speech device iteration is a musicPlayer or speechSynthesis device.
7. In the case of speechSynthesis, Big Talker then writes a log indicating that it is using speechSynthesis (sS), your speech devices visible name in SmartThings, and that it is sending the Speak() command
8. Big Talker calls the speak() command for your device passing it the desired phrase
9. LANdroid Alerter receives the speak() command with the desired phrase
10. LANdroid Alerter trims the phrase, removing beginning and trailing spaces
11. LANdroid Alerter creates a URL string to send
/&SPEAK=Front Door is now open&@DONE@ (spaces in a URI should actually be %20, so technically it should look like this:
/&SPEAK=Front%20Door%20is%20now%20open&@DONE@, but it may be ok with spaces, I'm not sure how SmartThings HubAction handles this, most browsers do it on the fly and it may as well (see URI percent-encoding)
12. LANdroid Alerter then creates and calls a SmartThings hubaction to send the URL string to the LANnouncer app on your android device on your local network.
13. repeat from 5 for each configured speech device.
In short, please turn on debug logging in Big Talker 1.1.4-Betaxx, go to Live Logging, cause BigTalker to attempt to send speech to your device, then capture those logs and PM to me if you would like me to look at it and try to catch/fix a related bug. Also, at the same time check SmartThings Live Logging for LANdroid Alerter when speech is expected from BigTalker to see if it is throwing any errors and/or showing what is expected.
@NWTony are there instructions to get this running? I installed lannouncer from the play store and then in ST searched for new devices (nothing). Then rather than poke around more I just asked you
Check post #1 in this thread, there are links to instructions there.
Is there an updated link? This one is broken.
Take a look here
Strange... it's working for me. Where is it sending you?
So glad to see a simple android client! Any chance you’d consider adding the ability to play certain audio files? I primarily want to have some recorded messages outside when unexpected motion is detected “intruder detected” or “please approach the console to identify yourself” and would prefer it not sound tts-y.
BigTalker 1.1.4-Beta8 should now be working with Lannouncer (LanDroid).
Latest community post regarding resolving this: [OBSOLETE 1.1.6 5/25/16] Big Talker - Talk when events occur
Please test and PM me to let me know if this resolves the issues you had or not.
I hope some one will help me on this, I am using the Lannouncer setup (tried with two different phones) Alarm or Siren is playing only for 3 to 4 sec and stopping, I tried everything on the phone like changing different ip address and reinstalled the “Lannouncer” but no luck, and also same issue with the curl commnads too.
any idea on this ? does this time setup some where in the Lannouncer app itself ?
What would the commands be to get a chime then a spoken message? I tried “SPEAK=@|ALARM=CHIME&SPEAK=Hello” but both happen at the same time. What am I missing?
Not missing anything. I’ve received a few requests to queue up sounds rather than interrupt current with new ones. My initial thoughts were that you’d always want the most recently-triggered one. Expect an update by end of March with this.
Strangely enough after testing it is been working as intended I hear the chime and then announces front door open
is there a way to adjust the duration of the siren when it is triggered? I would like to keep it firing off until I manually turn it off when it is triggered by an event.Thanks
Not yet, although I could possibly add that. The new version does support you using your own media file and adds a “STOP” command, so you could handle it that way.
little help wanted, i have set to announce when someone leaves and arrives, how ever, smartthings has told me i have left yet i have not?
If it’s Android, you could try looking here…
Of course, there are probably other threads about it too, but since that one is fresh on my mind from dealing with the same thing, I figured I’d share it.