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.