Media player: "stop music" is routed to HassTurnOff and fails when turn_off is unsupported

[michalkrzempek]

Bug

A spoken request to stop music can be classified as turn_off for a media_player, which HA-Jev then routes to Home Assistant's HassTurnOff intent.

That fails for media players which support pause/stop but do not support media_player.turn_off.

Environment

• HA-Jev: 1.16.0
• Home Assistant Core: 2026.9.3
• Target: Music Assistant media_player

Reproduction

Spoken Polish command:

Wyłącz muzykę.

("Turn off / stop the music.")

Assist STT recognized it correctly.

HA-Jev diagnostics:

Jev: turn_off, ok, confidence 0.97
Slots: {
  "name": {"value": "Chromecast Audio"},
  "domain": {"value": ["media_player"]},
  "preferred_area_id": {"value": "salon"}
}
entity: media_player.chromecast_audio 0.93
domain: media_player 1.00

The selected entity was correct. The failure happened when HA-Jev executed HassTurnOff:

intent HassTurnOff failed: Failed to call turn_off for: ['media_player.chromecast_audio']

homeassistant.exceptions.ServiceNotSupported:
Entity media_player.chromecast_audio does not support action media_player.turn_off

Home Assistant then returned:

Podczas przetwarzania zapytania wystąpił nieoczekiwany błąd

("An unexpected error occurred while processing the request.")

Why this appears to come from HA-Jev routing

Current custom_components/jev/interpret.py describes:

"turn_off": "Switch something off, close it, or stop it"

and maps:

"turn_off": ha_intent.INTENT_TURN_OFF

So "stop it" is semantically grouped with generic HassTurnOff.

The conversation tests also explicitly expect media players to use turn_on / turn_off:

("media_player.tv", "off", "turn_on", "turn_off")

This works only for media players implementing the turn-off feature. Many playback entities instead implement media pause/stop.

Home Assistant has a native HassMediaPause intent, and Music Assistant media players implement media_stop.

Expected behavior

For a request whose meaning is "stop/pause playback", HA-Jev should not issue HassTurnOff to a media player that does not support turning off.

Possible approaches:

1. add media-player-specific routing for stop/pause (for example HassMediaPause), or
2. route such requests to the fallback agent, or
3. make the action capability-aware before executing HassTurnOff.

The important part is to distinguish turning a media device off from stopping its playback.

Related

This looks like the same general class of domain-specific semantics that was addressed for locks in #5 / PR #6, but this is a separate case for media_player.

I can reproduce this consistently with a Music Assistant player that supports playback stop/pause but not media_player.turn_off.

[michalkrzempek]

Additional reproduction: the same domain-semantic problem also breaks starting playback, not only stopping it.

Spoken Polish command:

Puść mi metallikę w salonie.

("Play Metallica for me in the living room.")

STT recognized the sentence correctly.

HA-Jev trace:

Jev: turn_on, ok, confidence 0.69
Slots: {
  "name": {"value": "Chromecast Audio"},
  "domain": {"value": ["media_player"]},
  "preferred_area_id": {"value": "salon"}
}

action: turn_on 0.69
target_type: area 0.89
entity: media_player.chromecast_audio 0.80
area: Salon 1.00
domain: media_player 0.99

The entity and area resolution are correct, but the action is wrong. HA-Jev routes the request to:

HassTurnOn -> media_player.turn_on

and Home Assistant raises:

homeassistant.exceptions.ServiceNotSupported:
Entity media_player.chromecast_audio does not support action media_player.turn_on

In this setup, playback requests are supposed to go through the exposed Music Assistant voice script:

script.llm_script_for_music_assistant_voice_requests

HA-Jev did see that script as a candidate, but ranked it far below the media player itself:

media_player.chromecast_audio 0.81
script.llm_script_for_music_assistant_voice_requests 0.09

So this appears to confirm that the issue is broader than "stop music":

• playback semantics are being collapsed into generic turn_on
• stop semantics are being collapsed into generic turn_off

For media players, "play/start media" and "power on" are not equivalent operations, just as "stop playback" and "power off" are not equivalent.

This second reproducer may make the fix direction clearer: media-player commands need domain-specific routing/capability checks, or should fall back when the requested operation is playback-related rather than power-related.

[michalkrzempek]

I found another Jev-based Home Assistant conversation integration that handles media players in a more domain-specific way and may be a useful reference for fixing this:

https://github.com/JanOstrowka/typesafe-assist

Relevant implementation:
https://github.com/JanOstrowka/typesafe-assist/blob/main/custom_components/typesafe_conversation/questions.py

Unlike HA-Jev's current generic action mapping:

turn_on  -> "Switch something on, open it, start it, or run a script or scene"
turn_off -> "Switch something off, close it, or stop it"

that project exposes dedicated Home Assistant media intents to Jev:

HassSetVolume
HassMediaPause
HassMediaUnpause
HassMediaNext
HassMediaPrevious
HassMediaPlayerMute
HassMediaPlayerUnmute

For example, its intent criteria explicitly include:

HassMediaPause   -> "Pause music, video or media playback."
HassMediaUnpause -> "Resume or continue paused music/media playback."
HassMediaNext    -> "Skip to the next track, song or item."

At the same time, its HassTurnOn / HassTurnOff descriptions do not use generic media semantics such as "start it" / "stop it" for arbitrary media_player commands. This avoids collapsing playback semantics into device power semantics.

The other important pattern is fallback behavior. If the request is not represented by one of the supported native intents, the original utterance is handed untouched to the fallback conversation agent.

That seems like a very good fit for commands such as:

"Play Metallica in the living room"
"Play my Metallica playlist"

because those require media search/content selection and should not become HassTurnOn. In a setup with Music Assistant, the fallback LLM can then invoke the exposed Music Assistant voice script/tool with the required arguments (media_type, media_id, artist, album, shuffle, target player/area, etc.).

So a possible fix direction for HA-Jev would be:

1. Add the dedicated native media intents that Home Assistant already exposes for pause/resume/next/previous/mute/volume.
2. Remove generic playback wording from the turn_on / turn_off criteria for media_player.
3. Let playback/search requests that are not representable as native intents fall through to the configured fallback agent instead of approximating them as power on/off.

This would preserve Jev for fast deterministic device control, while avoiding the current failure mode where "play music" becomes HassTurnOn and "stop music" becomes HassTurnOff.

[AboveColin]

Thanks for the traces. They made this easy to reproduce.

Fixed in 1.16.1 (#36), in two parts.

1. The action criteria no longer say "start it" or "stop it". Playing, pausing, stopping and skipping media are now listed under none_of_these, so these sentences go to your fallback agent. I measured it on hosted Jev with a playing Chromecast Audio exposed. "stop the music" went from turn_off 0.98 to none_of_these 0.99. "Wyłącz muzykę." went from turn_off 0.98 to none_of_these 0.93. "play Metallica in the salon" went from turn_on 0.43 to none_of_these 0.99. "turn off the TV" and "Wyłącz telewizor" still come back turn_off.
2. When Home Assistant cannot do the action on any target, the sentence goes to the fallback agent. Before, Jev answered with an error. So a player with no turn_off no longer ends in "unexpected error". Your fallback agent gets the sentence unchanged, and it can call the Music Assistant script.

Your report made me look for other sentences that Jev reads as on or off when they are not. I found two more kinds and fixed them in the same PR. "turn off the lamp in 10 minutes" scored turn_off 0.97, and Home Assistant would have turned it off at once. "open the blinds halfway" scored turn_on 0.80, and the blinds would have opened fully. Jev now asks two more questions, one for a time or condition and one for a cover part of the way. Commands like these go to the fallback agent. In a test of 37 sentences, all 15 of these refused, and brightness levels and state questions still act.

I did not add HassMediaPause and the other media intents in this release. Now playback reaches your fallback agent, which can already do it. If a fast path for pause and next track would help you, tell me and I will look at it as a separate change.

If something still goes wrong after you update, a trace helps me most. In the Assist dialog, the "Jev:" note under the reply has the decision, its reason and the answers. For a satellite, the same note is in Settings, Voice assistants, the pipeline's menu, Debug. Download diagnostics on the Jev entry gives the last 20 decisions with the sentence redacted.