Spotcast starts Spotify playback on an idle Chromecast, and it is abandoned

An abandoned component with an explicit successor

Spotcast is a Home Assistant custom component for starting Spotify playback on an idle Chromecast device or on a Spotify Connect device, and the first thing the README says is that the project is abandoned and no longer maintained.

The reasons given are specific rather than vague: Spotify's hostility toward third-party developers, their political stances, and a lack of time on the maintainer's part. The decision is to discontinue the project indefinitely, with no pull requests reviewed or merged.

Then it names where to go next. A maintained fork lives at Mincka/spotcast, with a migration guide, and the README states that your accounts, tokens, entities and automations carry over untouched. There is also a separate warning about a breaking change in Home Assistant 2024.11 breaking the Spotify-Card custom card, which cannot be fixed here because the project has no active maintainer, with a pointer to a fork of that card instead.

That warning about Spotify-Card is worth separating from the rest. A Spotify-Card user needs to move to a different project entirely, and the README is explicit that this project and its maintainers do not manage the other project and cannot help with it directly.

So the practical state of play is that the original repository is a reference implementation and a set of instructions for moving away from it. The last push was on 2026-07-23 and the repository is not marked archived, but the warning banner is the authoritative status.

It implements a cast platform, not a media player

The scope of the component is narrow and the README is precise about it.

Spotcast implements a cast platform, which requires Home Assistant Core 2022.2.0 or later, and that enables Google Cast media player entities to play Spotify URIs as well as to browse the Spotify library.

The README also says the component is not meant to be a full Spotify Chromecast media_player but only serves to start the playback. Controlling the Chromecast device and the Spotify playback after the initial start is done in their respective components.

That distinction is the design. Home Assistant's Chromecast integration already handles transport controls, volume and device management for a Cast device. What it cannot do is hand a Spotify URI to that device, because Cast media playback is a protocol with a receiver on the other side. Spotcast supplies the receiver side and the handoff, so the existing Chromecast media player entity becomes targetable with a playlist, and then the ordinary media controls take over.

Supporting Spotify Connect devices as well as Chromecast is the other half of the scope, credited in the README to @kleinc80. The stated benefit is that an automation can target a Chromecast or a Connect device with the same shape of call, so a single automation does not have to know which kind of device it is speaking to.

Why browser cookies are the authentication mechanism

The authentication story is the part that most affects whether this component works for you, and the README explains it rather than hiding it.

Spotcast uses two cookies to authenticate against Spotify in order to have access to the required services. They are sp_dc and sp_key.

The reason is stated in one line: because starting playback using the API requires more powerful token, the username and password used for browser login is used instead.

So the component authenticates as a logged-in browser session rather than with an OAuth client token. That is what makes it possible to drive playback at all, since the API path needs a stronger credential than a custom component can obtain on its own.

The cookies are obtained by hand, and the README gives step by step instructions for both Chrome and Firefox. In Chrome you open an incognito window at open.spotify.com, log in, open the developer tools with Command+Option+I on Mac or Control+Shift+I or F12, go into the application section, then Storage, Cookies, open.spotify.com, and copy the sp_dc and sp_key values.

The last step is the one people get wrong. Close the window without logging out, otherwise the cookies are made invalid.

The same warning appears in both the Chrome and the Firefox instructions, which tells you it is the most common failure point.

Configuration, secrets and multiple accounts

The configuration goes into configuration.yaml, and the README is careful to point you at secrets rather than plain text.

For a single account, the block is short.

spotcast:
  sp_dc: !secret sp_dc
  sp_key: !secret sp_key
  country: SE #optional, added in 3.6.24

The country field is optional and marked as added in 3.6.24.

Multiple accounts are an accounts dictionary, populated with a list of accounts, so playback can be initiated using different accounts than the default.

spotcast:
  sp_dc: !secret primary_sp_dc
  sp_key: !secret primary_sp_key
  country: SE #optional, added in 3.6.24
  accounts:
    niklas:
      sp_dc: !secret niklas_sp_dc
      sp_key: !secret niklas_sp_key
    ming:
      sp_dc: !secret ming_sp_dc
      sp_key: !secret ming_sp_key

The !secret tag is the mechanism Home Assistant uses to look inside secrets.yaml instead, and the README notes that configuration.yaml is a plain text file and that storing passwords there is not recommended.

sp_dc: [your sp_dc here]
sp_key: [your sp_key here]

One dependency is easy to miss. As of v3.5.2 you must also have the official Home Assistant Spotify integration installed and configured, because it provides the correct device list which has the correct scopes in its token. If you use v3.5.2 or greater, the additional accounts also need to be added to that official integration as well, otherwise multiple accounts do not work.

Compatibility is stated as any version since 2024.11.0, and installation is either through HACS, which the README calls the easiest route, or by copying all files from custom_components/spotcast/ to the same path inside your Home Assistant config directory.

The service call takes a device or a name, and a URI

The component creates a service called spotcast.start in Home Assistant, and the two documented call shapes differ in how they identify the target.

Targeting a Spotify Connect device uses its device id.

- service: spotcast.start
  data:
    spotify_device_id: "ab123c5d7347324c2b1234567890f8d6dc40350"
    uri: "spotify:playlist:5xddIVAtLrZKtt4YGLM1SQ"
    random_song: true

Targeting a device with the default account uses a friendly name instead.

- service: spotcast.start
  data:
    device_name: "Kitchen"
    uri: "spotify:playlist:5xddIVAtLrZKtt4YGLM1SQ"
    random_song: true

The README then explains the fields: spotify_device_id is the device ID of the Spotify Connect device, and device_name is the friendly name of the Chromecast device,. The uri is a Spotify URI, here a playlist, and random_song is a boolean that appears in both examples.

For a Home Assistant user, this is a service call that drops into an automation like any other, and the random_song flag is the difference between starting the playlist as authored and starting a shuffle of it. Since the whole point of the component is starting playback on a device that is idle, that flag is likely the main reason an automation would use it.

The community post linked from the README is titled as a Spotcast custom component to start playback on an idle Chromecast device, which is the use case the service shape was designed around.

Where the repository shows its age

Several small inconsistencies in the repository tell you this component has been around a while and is no longer being tightened up.

The Makefile declares a version of 3.9.0, while the release tags in the repository history are 6.0.0-a16 from 2025-12-28, 6.0.0-a0 from 2025-05-18 and 5.0.0-b36 from 2025-04-19. So the Makefile version and the tagged versions do not agree, which suggests the version constant is used for the bump2version tool and has drifted from the release line.

The build tooling is dated in a useful way. The lint target runs isort, black and flake8 over custom_components, which was the standard Python formatting stack for Home Assistant custom components before the ecosystem moved to ruff. The install_dev target installs from requirements-dev.txt, and there is a separate requirements.txt.

The repository layout also shows the ecosystem context. There is a hacs.json, which is what HACS reads to list the integration, an info.md file for the HACS description, a container directory, a links.sh script, images, and a Makefile with a bump target that runs bump2version against both the Makefile and the component manifest.json so the version stays in step across two files.

The .bumpversion.cfg file at the root and the .vscode directory round out a repository that is set up for a maintainer workflow that is no longer running.

Where Spotcast is the wrong tool

The first limitation is the obvious one, and it dominates everything else. The project is discontinued, no pull requests will be reviewed or merged, and the reason given is a policy conflict with the upstream platform plus a lack of time. Adopting an unmaintained component that authenticates with copied browser cookies and talks to a platform that the maintainer describes as hostile to third-party developers is a bet that the upstream will not change in a way that breaks it.

The second limitation is the authentication mechanism itself. Using sp_dc and sp_key from a browser login session means the component holds credentials that are equivalent to a logged-in Spotify session, obtained by hand from a browser. Whatever the platform decides about those sessions, the component depends on them continuing to work exactly as they do now.

The third is scope. It only starts playback. Everything after that is someone else's component, so an automation built on spotcast.start still needs the right transport controls wired up separately.

The fourth is the dependency on the official Spotify integration from v3.5.2 onward, and the additional friction that multiple accounts must be registered in two places. That kind of coupling is exactly what breaks when the core integration changes, which is what the Spotify-Card situation illustrates.

And the fifth is that this is not a general Spotify integration for Home Assistant. If your need is to play music in a room and control it, the official integration is the thing to look at, and Spotcast only makes sense for the specific gap of starting Spotify content on a Cast device that is otherwise idle.

How it compares with the official Spotify integration

The alternative is the official Home Assistant Spotify integration, and the difference is the one the README keeps drawing.

The official integration provides the device list and a token with the correct scopes, and it manages Spotify Connect devices as media players. What it does not do, according to the README, is let you hand a Spotify URI to a Google Cast media player entity, which is the gap Spotcast fills.

So the two are not really competing. In a well configured install, the official integration is required anyway from v3.5.2 onward, and Spotcast sits on top of it adding the Cast-side handoff. That relationship makes them complementary rather than alternatives.

The other comparison is with a fork of the whole thing, and here the README is unambiguous. Rather than fixing the component in place, the maintainer discontinued it and pointed at Mincka/spotcast with a migration guide, stating that accounts, tokens, entities and automations carry over untouched. That is the difference between adopting a project and adopting a specific repository of it.

For an evaluator, the practical consequence is that the interesting engineering content in this repository, the cast platform implementation and the cookie handling, is what the fork now carries forward. Reading the original is useful for understanding the design and for checking what changed, but running the original when a maintained fork exists is a choice with no upside.

Editorial conclusion

Spotcast fits an existing Home Assistant install that already has the official Spotify integration and browser session cookies, and only makes sense for you if you are already running the component and want to understand how it works before migrating. It does not fit a new installation, because the project is discontinued, no pull requests will be reviewed, and the author states the reason is Spotify's hostility toward third-party developers. Before installing anything, read the maintenance notice at the top of the README, follow the migration guide from the maintained fork rather than installing the original, and check that your Home Assistant version is at least 2024.11.0 since the README says that is where compatibility starts.

Frequently asked questions

Official sources

1. fondberg/spotcast on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases