YandexStation: cloud control cannot read the speaker back

Four device classes, four different transport stories

The opening of the document is a four-row capability matrix, and it is the most valuable thing in it.

Speakers of the Yandex brand support local and cloud control at the same time. Speakers from other brands support cloud control only. Yandex Modules support local control only. Devices belonging to the Alice smart home support cloud control only.

So the transport is a property of the hardware, not a preference you set, and one of the four classes cannot be controlled through the cloud at all. The document then says outright that the functions and capabilities of local control greatly exceed cloud control, that cloud control is available on all speakers but not on modules, and that local mode switches on by itself on speakers that support it.

That last point has an operational consequence worth naming. There is no setting to enable local mode; if your hardware supports it you get it, and if it does not you cannot turn it on. Which means the size of the feature set you can depend on is decided when you buy the speaker, months before you install anything.

The document also flags, before getting into features, that it uses three different terms for the same concept, a local speaker, local mode, and local control, and warns the reader to establish carefully which speakers support it.

Cloud control has no read-back, and the document says so plainly

There is a short paragraph admitting that cloud control has no feedback from the speaker. It is unknown whether the speaker is playing anything or sitting paused, and what its current volume actually is. The conclusion drawn is that the speaker's state in Home Assistant can differ from its real state if you gave it commands from anywhere other than the component.

That is a write-only channel, and it is described as one rather than discovered later.

The practical consequences are immediate for anyone building automations. A condition like is it playing cannot be trusted over cloud. A volume slider is a command, not a reading. A routine that turns the volume down before a notification and restores it afterwards can restore it to the wrong number, because the component never learned what the number had become. And a speaker adjusted by voice or by its own buttons will drift out of sync with Home Assistant until the next component-originated command happens to be correct.

What the component can do is send commands. It sends playback and volume control, sends text to speech from the media player window and through services including by voice in the assistant's own voice, sends arbitrary text commands such as asking for music, and can layer a library of sound effects over that speech.

None of that requires reading the device, which is exactly why it works over cloud at all.

Knowing what is playing is a local-only feature, not a setting

The document splits its feature list into what all speakers support and what only local ones do, and the local-only additions are short but consequential.

Two of them: viewing what is currently playing on the speaker, including the cover art for music, and seeking or skipping within a track.

Both are absent from cloud. So on a non-Yandex brand speaker, which is cloud-only, Home Assistant can start playback but cannot show you the current track or let you move within it. The component is a remote control with no display and no transport bar.

For music, the cover art is further limited to music specifically, so even on a local-capable speaker that one piece of metadata is narrower than the rest.

The local-only portion of the table of contents is where the interesting capabilities cluster, and they are all things a cloud API cannot do: controlling text-to-speech volume, streaming music, karaoke, playing media from links, playing local music files, animating something on the speaker's own screen, receiving responses back from the speaker, bridging the assistant into Telegram, a shopping list, and giving the speaker a static IP address.

That last one is a network prerequisite hiding in a feature list. Local control implies the speaker is reachable directly, and the document does not explain how the two are related.

Two more sit outside the transport split entirely, under general functions: the speaker's audio over HDMI, which is about using the speaker as a television's sound output rather than about talking to it, and screen brightness control for one specific larger model.

It creates a scenario in your Yandex account, and repairs it with a restart

The configuration section opens with a warning. For each of your speakers, a service scenario will be created in the Yandex mobile application, named with two letters that look like the initials HA followed by a UUID. The instruction is not to touch it. If it is deleted by accident, restart Home Assistant.

So this is not a component that only talks to a cloud API. It provisions objects inside the user's Yandex account, one per speaker, on the account side of the vendor's platform. That is why the guidance is to leave them alone, and it is also why the recovery action is a Home Assistant restart rather than anything in the Yandex app: the objects are created from Home Assistant on startup, so a restart recreates them.

The use of Cyrillic lookalike characters for those two letters is a small detail that causes real friction. The scenario will appear in a Russian-language interface with letters that a user might type as Latin when searching for it, and nothing in the document explains the choice.

One more troubleshooting line is worth noting because it points somewhere unexpected: if the integration does not appear in the list, clear the browser cache. Home Assistant builds that list server-side, so a browser-side cache is not where that state lives.

Installation itself is two routes. One is through HACS as an integration. The other is copying the `yandex_station` folder out of the latest release into `/config/custom_components`, which makes the configuration directory the thing you upgrade by hand.

Seven authentication methods, graded, and one needs a second server

Authorization is the longest part of the setup section, and it is organised as a list graded by reliability rather than by preference.

Three are called stable. A QR code, which is the recommended one. Cookies, where the component tells you what to do. And a token, which carries a constraint that is easy to miss: it can only be copied from a different Home Assistant server where authorization has already been carried out.

That last clause rules the method out on a first install. There is no paste-a-token field to fill on the machine where you are setting things up for the first time; you would need a second Home Assistant instance that has already authenticated.

Four are called unstable, meaning they may not work. A password, for ordinary authorization. A one-time password from the Yandex.Key application with two-factor authorization enabled. An email link, noted as not supported on all accounts. And a fourth category the visible grouping does not enumerate beyond the three.

The security design underneath is sound and is stated explicitly: in the end the component obtains a Yandex token and stores exactly that, and your password is not stored anywhere. So the password is a transient input to an authorization flow rather than a retained credential, which is the right shape even though the password path is one of the unstable ones.

Accepting cookies as a supported method is the part with a different tradeoff, since a browser session is exactly what session theft targets.

Nine related components are listed and one of them is this repository

There is a section of useful components, opening with a bold statement that not all of them are by the author's hand.

Nine entries follow, and they divide cleanly. Six are the same author's: this repository itself, a component for receiving commands from Alice devices through the vendor's dialogs platform, a tool for trying Home Assistant on a Windows computer, a tool for limiting public HTTPS access to a Home Assistant server, a library for declining numerals correctly in Russian, and one for zone-based vacuum cleaning on certain robot vacuums by voice.

Three are other people's: one for adding Home Assistant devices into the Yandex smart home, one for browsing and playing tracks from the vendor's music service, and one for receiving commands through vendor scenarios rather than dialogs.

So a list presented as a set of nine recommendations includes the project doing the recommending as the first entry.

Two of the six are worth a second look because they reveal what this author actually builds. The numeral-declining library exists because Russian requires grammatical agreement with numbers, so a text-to-speech system saying twenty-one or twenty-two produces a grammatical error unless the number is inflected first. Building a small library for that, and using it for both speech and Telegram output, is the kind of detail that only surfaces when someone has shipped the integration.

The public access tool points the other way. Alongside a component that keeps cloud credentials and provisions vendor-side scenarios, the author also ships something for closing off public access to a Home Assistant instance, which suggests the security posture is considered rather than incidental.

Editorial conclusion

The transport split is the thing to understand before configuring anything, because it determines which features exist rather than how well they work. If your speaker is a Yandex brand, you get the local protocol and the larger feature set, including knowing what is playing. If it is not, plan automations around commands and never around playback state, because the README states plainly that there is no feedback on that path. Install via HACS if you can, since the manual route copies a folder out of a release into your configuration directory and you then own upgrades. And use the QR code for authorization: the token method as documented cannot be used on a first server at all.

Frequently asked questions

Official sources

1. AlexxIT/YandexStation on GitHub
2. License: MIT
3. Project website
4. README
5. Releases