This allows skill writers to ignore naming intents. Combined with a
forthcoming change to Adapt that creates a default of None for IntentBuilder()
This allows the current:
@intent_handler(IntentBuilder("CurrentWeatherIntent").require(
"Weather").optionally("Location").build())
def handle_current_weather(self, message):
...
To become:
@intent_handler(IntentBuilder().require("Weather").optionally("Location"))
def handle_current_weather(self, message):
...
Which will automatically name the Intent "handle_current_weather".
Also dropped the log message in the default initialize() method since it is
common to not override it now.
If the machine is not connected to the network getting the user uuid in MutableMic.__init__ will fail, raising ConnectionError. This caused the speech client to crash.
Adding handler for ConnectionError resolves this issue.
==== Tech Notes ====
Configuration.get() was originally thought to take a stack of configuration dicts and merge together into a single configuration dict but can also handle file paths.
The Api() class can't use the RemoteConfig class so it has supplied it's own stack of configuration files to avoid infinite recursion. Previously the files wore converted to dicts before passed into the Configuration which meant that 3 files were loaded even if the information was already cached. This passes the files as file references that will only be converted to dicts if the cache is not found.
In code like this:
self.speak_dialog("something")
mycroft.audio.wait_while_speaking()
It was possible that the speaking of "something" would take longer to
start than the 0.1 seconds that was built into the wait_while_speaking().
The definition of this behavior is slightly fuzzy, but this is definitely
a case where the expectation is that previous request for speech would
start and complete. For now, I have just bumped the minimum wait to
0.3 seconds.
In the long run we might consider tracking specific speak requests and
generating a notification when that request has been serviced. Then the
skill could automatically hold off until that request has been serviced.
But the basic skill code won't have to change to make this happen, so
this additional sleep is adequate for today.
Also snuck in a minor change to a comment.
Add support for 'mycroft.mic.listen' on the messagebus to trigger the system
to listen for STT processing. This can be posted on the messagebus by outside
systems, such as a physical or GUI Listen button.
The recent change to remove Pystache introduced a bug in cases where
the passed-in key/value data included non-strings for the value. This
showed up in the weather skill which passed in "lat" and "lon" as floats.
Now the value is explicitly converted using str().
When the TTS engine provides visemes to the faceplate, the information
passed along consists of the mouth shape and the duration to display it.
When the system get backed-up for some reason (e.g. the CPU is briefly
overloaded), the code would attempt to catch up the animation but would
still send the 'expired' viseme across the serial port to the faceplate
with no wait-time. This results in a fast-moving mouth to catch up,
which isn't very pleasing.
Now the viseme is passed along with an expiration date, so if the time
to display it has already passed then the viseme code gets thrown away
instead of being sent across the (relatively slow) serial port. This
allows better catch-up.
Several refinements:
* Remove the "What time is it" preloaded example
* Page up/down now moves by 1/2 the # visible log lines instead of always 10 lines
* Reduce the frequency of full-screen redraws to 10 secs instead of 5 (because less needed with the corruption fix)
* Add the version of mycroft-core in the upper-right corner
* FIX: screen redraw now uses a lock, preventing corruption from drawing simultaneously from multiple threads
On certain platforms it escapes quotes which causes problems. Since we only use it for something as simple as key value replacements, it doesn't make sense to include it as a dependency
As noted on the Chromium Dev How-to [1] and on the
SpeechRecognition library docs [2], the Google TTS API
is really not the right API to call. While it's simple,
and allows you to authenticate via a simple token, it is
also limited to a max of *50* requests per day.
That's not a lot. I don't think many people will find that
useful, outside of quick testing (if they can even get an
API key - I couldn't figure out how to generate one that
worked correctly).
This commit introduces a new STT backend, google_cloud, so that
the Google STT backend can be deprecated eventually. To do so, we
needed to:
- Install the Google API Client Library
- Create a new STT class which knows how to turn a provided Google
JSON credentials file into a string (the SpeechRecognition library
expects you to pass in the JSON string, not a file path, nor an object).
Any person wishing to use this will need to:
- Enable the Cloud Speech API on the Google Cloud Platform console
- Create a new Service Account Key, and download the credentials to
a secure location
- Configure that location in mycroft.conf, like so:
"stt": {
"google_cloud": {
"credential" {
"json": { contents of downloaded credentials }
}
}
}
It's worth noting that the Cloud Speech API has a free quota of
60 minutes per month, which would probably stretch further than 50
individual requests. So for hobbyists, it should be nothing but
a net benefit.
[1] http://www.chromium.org/developers/how-tos/api-keys
[2] https://github.com/Uberi/speech_recognition/blob/master/reference/library-reference.rst#recognizer_instancerecognize_googleaudio_data-key--none-language--en-us-show_all--false
==== Tech notes ====
The send script will throw an IOerror exception if the bus service isn't
started. This correctly catches it and emits a single warning.
Matthew D. Scholefield
penrods
Åke
JarbasAI
devs-mycroft
KathyReid
gaurav
Augusto Monteiro
Michael Nguyen
Andrew Hayworth