Stypox
Add skill to disable/enable listening for wake word
Hello!
This pull request contains a simple skill to enable and disable wake word detection. The use case is that sometimes I may be at a location where it would be very problematic to have my phone's microphone activated, and it would make me feel more comfortable if I could easily disable Dicio's wake word detection feature.
I want to be able to easily say, "Hey Dicio, stop listening," and then have it no longer listen for the wake word until I go into the app and explicitly re-enable it. That could either be in the settings page or by manually triggering Dicio and saying "Start listening." This is what I've implemented. I also included some other aliases, such as "mute microphone" and "unmute microphone." (I also included "on mute microphone" as an alias for "unmute microphone" because the Speech-to-Text algorithm interprets my accent that way.)
Some quick background: I'm interested in building some complex voice assistant skills that aren't available on commercially available assistants. Dicio looks like a good platform to use for this, but since I only started learning Android development and Kotlin three hours ago, I figured I'd try some building some simpler skills first.
I would like to contribute back this skill and potentially any other skills I make, but I'm not sure whether they would be useful to a wider audience. If not, I'm happy to keep them in my own fork.
I'm not totally happy with how I implemented this skill, particularly the SettingsAccess proxy, so if you have any feedback on the code and/or design, I would be very interested in hearing it.
Thank you for your time!
Thanks! I will make these changes. Note that there was a reason I didn't pass the DataStore<UserSettings> directly to skills: I would have had to move UserSettings to the skill/ module, which seems even worse than moving InteractionLog.
Thanks! I will make these changes. Note that there was a reason I didn't pass the DataStore<UserSettings> directly to skills: I would have had to move UserSettings to the skill/ module, which seems even worse than moving InteractionLog.
That's true. One alternative would be to add @Singleton on the ListeningInfo class, making it injectable by Hilt, and add a DataStore<UserSettings> parameter in the constructor of ListeningInfo. Then you could add a listeningInfo: ListeningInfo parameter to the constructor of SkillHandler which will be injected automatically. This way the ListeningInfo would get hold of DataStore<UserSettings> and could use it to build ListeningSkill.
