-
-
Notifications
You must be signed in to change notification settings - Fork 101
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
Enable Proper Echo Device PLayback in Spotcast #403
Comments
Update:Still crashing in latest Spotcast version [3.7.1] Even if I used directly the spotify_device_id in the spotcast call .. Unfortunately the crash stops the script from running even if I use continue_on_error .. This means I cannot catch the error and do a second call.. The second time I run exactly the same script it works.. music starts playing.. The complexity of the problem can be explained in a pseudo-dramatic phrase: At this moment, because of this bug it's impossible to automate playing music using Spotify in Home Assistant on an idle device. 🥲 Below some info.
|
Echoes are very finicky, is the device available from device list in spotify console when idle? |
Yes, the device is available in the devices list. Here's a part of the response from
After making sure the deive is in the list I called: service: spotcast.start Same error: Logger: homeassistant.helpers.script.websocket_api_script websocket_api script: Error executing script. Unexpected error for call_service at pos 1: http status: 404, code:-1 - https://api.spotify.com/v1/me/player/play?device_id=xxx_amzn_2: Not found., reason: None During handling of the above exception, another exception occurred: Traceback (most recent call last): |
The ugliest part of this is that this error completely breaks any automation. Home Assistant uses continue_on_error for HomeAssistantError
|
Have you tried directly with the device Id, because the device name is used to register a Chromecast device to a Spotify session, it should actually fail in the way you are using it. |
Yes. I tried using directly the spotify_device_id
I tried all possible options: same result every time. I tried different Amazon Echo devices too. |
i have the same issue with my echo dot, i hope we found a solution :( |
@fcusson any news for this Problem? |
Still the same problem in March 2024. |
I still get this, no idea how to fix it. |
Same issue for me with Denon receiver Traceback (most recent call last): |
In its current state (v3) the code can only register and wake up a Chromecast device. All other devices are expected to register by themselves. The refactor I'm working on (v4) will be able to expand to other speaker technology, but this will be up to the community to build the connectors as I only have Chromecast devices currently. Since this is a complete rewrite and I'm working on it alone in my free time this could be months before this is ready. |
Im using the endpoint https://api.spotify.com/v1/me/player/devices to get the device ID and putting the device ID into the "Spotify Device ID" field in spotcast. Still getting this weird error. When i connect from my phone to the device it plays fine. The Denon receiver is turned on....Not sure what im supposed to wake up... |
@miumer I did the same, same result. :( |
@fcusson @AeroV95 @miumer @duczz I tried making Spotcast work with Amazon Echo devices (Spotify Connect devices) a few months in all possible ways and trying again after each Spotcast new update. No luck yet. But here is what I noticed: When I try playing on an idle Spotify Connect device (Amazon Echo in my case) the first time, Spotcast will crash with an error. But if I retry the same script call after that error, the Spotcast play will work fine. This means that, during the "crash", Spotcast actually managed to wake up the device. Unfortunatelly the first crash will trigger an error and stop the script. Maybe we can work something out based on this finding? Thoughts? |
@raresdragan this would require a revamp of the error management. Currently, a lot of the processes in the integration do not cleanly raise a Short term, this could be simply wrapping the service call in a Long term, we would need a proper system to wake up an echo device and register the account to the spotify account requested. The current method you are using (spotify_id call) was meant for a device already registered to the spotify account. The fact it works on the second time is an happy side-effect of what we are doing. Not a controlled consequence. To be able to integrate Echo Devices correctly, this would need to be integrated in V4 which I'm currently working on my fork. Any help is appreciated as I do not own echo devices |
i think spotifyplus can do this things and more, maybe fcusson can get some informations from him? or this changes can be implement in the nativ spotify integration |
@duczz as mentioned I do not have an echo device someone else with the device will have to do the research and testing but I am working on an easier way to add protocol for other smart speaker in v4. |
@raresdragan should be available shortly, just pushed the change, but need to test it when I get home |
renamed ticket to better encapulate the expected outcome and moved to beta improvement. |
Bug Ticket
Description
I think this issue was reported before (last time in 2022?) just letting you know it's still a problem in September 2023 wit the latest Spotcast version / latest Home Assistant / everything up to date, premium Spotify account, etc.
System is a Raspberry PI 3 which works great otherwise.
When I try to play Spotify music using Spotcast to my Amazon Echo using the device name the first time it crashes, the second time it works fine.
I did a quick workaround to play first a silent track and second time the right track .. But I'm wondering .. can't this be fixed in the Spotcast directly? It seems like an extra call is needed to wake up the device? Can I help in any way fixing this?
Service Call
service: spotcast.start
data:
force_playback: true
uri: spotify:track:6mcxQ1Y3uQRU0IHsvdNLH1
start_volume: 25
device_name: Echo
Debug info
I provided (hopefully) some relevant debug info below:
(I censored my amazon device id with xxx )
SECOND TIME CALLING THE SAME SCRIPT IT WORKS:
Troubleshooting
Make sure to validate all the elements before submitting the ticket (Exception to the steps marked as optional)
sp_dc
andsp_key
values and restarted Home Assistant (see README)The text was updated successfully, but these errors were encountered: