Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Implement new audio notification API #21

Open
vanto opened this issue Feb 5, 2018 · 2 comments
Open

Feature Request: Implement new audio notification API #21

vanto opened this issue Feb 5, 2018 · 2 comments

Comments

@vanto
Copy link
Contributor

vanto commented Feb 5, 2018

With firmware 17.x Bose has introduced a new API for audio notifications:

Upon initiating playback of an Audio Notification using this API, the target speaker will gracefully stop whatever its doing, play the Audio Notification, and then resume whatever it was doing. So, a speaker in standby will wake up, play the Audio Notification, and go back to standby, while a speaker that is playing music will switch to play the Audio Notification, then return to the music that was playing.

https://developer.bose.com/soundtouch-audio-notification-api/apis

This is just perfect for TTS notifications from smart home solutions like home-assistant.

It would be great to see support for this API being added to this great lib.

@CharlesBlonde
Copy link
Owner

Hi @vanto

It's a great feature I was waiting for and it's working fine ... but there is a drawback !
You have to create a Bose application in order to get an API key. I don't understand why it is mandatory because in my use case I don't need it. I just want to be able to play an HTTP(S) URL.

I did some first test and it's working fine. While the speaker is playing content (eg: Spotify), it stop the current content, play the HTTP url and continue playing the previous content. Perfect.

I'll try to contact Bose and I'll do the first implementation. But I think I'll have to publish my API Key or ask users to create their own Bose application (neither of this 2 solutions are perfect)

@vanto
Copy link
Contributor Author

vanto commented Feb 10, 2018

I did the same experiments and wondered about the same thing. Also, I don't understand why a local connection to a device demands for a global, vendor registered key. To me this is a non-sense move for such an API. Anyways, they seem to use the API key to gather some metrics (you can see them in the "my apps" area in their dev portal), which means the key seems to be used for rate limiting as well. A normal key is limited to 100 Audio Notification API calls per day, so I assume the only possibility is to ask users to register and create their own keys. Bose seems to offer something with their Partner program, but I assume this won't fit well to open source, which would mean that the partner key would be publicly available. Good luck with the discussion with them. The perfect way would be to convince them to refrain from requiring a key for local network activities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants