CharlesBlonde
Feature Request: Implement new audio notification API
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.
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)
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.