Add volume_step data parameter to media_player.volume_up / volume_down service calls

[glenrobertson]

Hi all!

I opened home-assistant/core#90283 to add a volume_step parameter to the media_player.volume_up / media_player.volume_down service calls.
Currently there is a 10% value hardcoded across all media_player entities, so this would allow a caller to configure that, as follows:

Any feedback or discussion appreciated. Thanks in advance!

[mvdwetering]

There are muiltiple integrations that communicate with devices that offer a "volume-step-up/down" command. Those commands are mostly that, just step up/down without a way to indicate stepsize.

Allowing to pass in arbitrary values through the service call makes it impossible to use those native step commands. By providing arbitrary values basically all you can do is take current volume and add or subtract the step value. Which is also how some integrations implement the VOLUME_STEP feature.
However that would not work if your media_player can only support VOLUME_STEP and not VOLUME_SET. Which is possible to indicate with supported_features, but I did not check if such media_players currently exist in HA.

I think the real question is: shouldn't integrations that indicate support for volume step implement a proper stepsize?

Question then of course becomes what a proper stepsize is. Which in turn depends on what the intended use of the VOLUME_STEP feature is.

I don't know what the original background of the VOLUME_STEP feature is, but I would expect to be able to control the volume like I would with a TV remote control or the volume up/down buttons on my PC keyboard. These are typically small steps to make the sound a bit louder/less loud.

Maybe lets look at some examples of devices that offer volume step up/down functionality (just picked some I have easy access to):

• Windows 11, range 0-100, stepsize 2 = 2%
• Sonos App, range 0-100, stepsize 2 or 4 (stepsize seems to change for higher volumes) = 2% or 4%
• Android phone volume for media playback, range is 0-25 it seems, stepsize = 1 = 4%
• Yamaha receiver, -80.5 to 16.5dB, stepsize 0.5dB = about 0.5%

Maybe the default stepsize should just be smaller than 10% instead of making it variable?

That would give more steps for all integrations using the default implementation (a very quick search seems to indicate ~70 integrations support VOLUME_STEP feature and about 50 integrations have an implementation for (async)_volume_up).
Note that very small default steps might give issues with integrations where the achieveable stepssize on the device is smaller than the default stepsize chosen. But then again they can be fixed by providing a custom implementation for volume_up/down.

(on a sidenote, it looks like the media_player group also does the 10% steps and not call the volume up/down of its members, that might also need updating)

I am sorry I don't ahve a direct solution and it got a bit longer than expected when I started writing, but I kept finding new stuff. I hope this is of some help.

[glenrobertson]

Thank you for replying and providing the context.
I think I agree that the integrations should provide a sensible step size. With this change, I figured that users may want to customize it easily without having to delve into the integration code
Like even if my receiver has a sensible step up or down, I may wish to half or double it to my liking.
Happy to close if you disagree or merge if you do agree.

Thanks again

[mvdwetering]

Happy to close if you disagree or merge if you do agree.

I was just tyring to provide some additonal scenarios. I don't have the power to actually decide on stuff :)

[glenrobertson]

Nobody has commented on this so I'm just gonna close. Can re open if there is interest.

[gjohansson-ST]

I'll re-open this as the topic is still valid to take a decision upon.

[glenrobertson]

Closing but I can't close the other PR I opened so someone else is gonna have to do that lol.

[gjohansson-ST]

Not sure why you're still trying to close this. It's still valid I believe

[emontnemery]

Yes, this is indeed still valid 👍

There's a problem with the proposal though; the reason behind the media_player.volume_up / media_player.volume_down services is that some media players don't allow setting an absolute volume. An example is an amplifier with a motorized volume knob which does not know its position which means it's only possible to request the volume to be increased or decreased by an unknown amount.

Hence, it would be better to add a volume_step parameter to media_player.volume_set instead, where volume_step would be a positive or negative float. This would be similar to brightness_step for light.turn_on.

[glenrobertson]

Ok thanks for addressing it. I had closed as it was stale and I personally don't like keeping PRs open for 6 months, but appreciate you finally getting to this.
I can reopen the PR and implement how you've suggested.

[emontnemery]

I discussed this with @balloob, @edenhaus and @MartinHjelmare. The conclusion is that the proposal is fine; the volume_step service call parameter should just be filtered in service.yaml for media players which don't support media_player.volume_set.

[gjohansson-ST]

As far as I know you can't do negative filtering e.g. only showing the field if entity does not have media_player.volume_set.
Or am I missing what you meant?

[andrewsayre]

I think he meant filter the parameter by support for VOLUME_STEP, something like this:

volume_set:
  ...
  fields:
    ...
    volume_step:
      filter:
        supported_features:
          - media_player.MediaPlayerEntityFeature.VOLUME_STEP
      required: false
      selector:
        number:
          min: 0
          max: 1
          step: 0.01

[andrewsayre]

@emontnemery Why not also add volume_step as an optional parameter to the volume up/down services as well? Those services already require both VOLUME_SET and VOLUME_STEP. If a platform doesn't support a custom step size it was already using a custom implementation of those actions and (likely) not using the built in 10% default anyway. It can just ignore the field, or would it be better to raise a ServiceValidationException?

[aodtcr]

Hi all, just arrived at this discussion after looking into changing the default volume_step for a new media player (AVR). The default for the AVR is + or - 0.5 dB (remote or volume knob) while changing the volume with the buttons in HA results in + or - 10 dB. (10% of 100 step range). This is very undesirable behavior.

I'd love to see a way to either have this smaller by default (e.g. 1%) or a per device (integration) or global setting for personal preference and tweaking.

[andrewsayre]

@glenrobertson I think this is worth implementing. Some integrations have added config options to set an integration default volume step because the default base implementation of 10% is too much. For some use cases, that wouldn't have been necessary if the services had this parameter.

As another datapoint, HEOS also has native support for volume up/down with a specified step (default is 5%). So that's another integration that would benefit from this feature.

Per @emontnemery comment, this proposal appears to be approved. Do you want to work on the implementation? If not, I'm happy to move it forward.

[glenrobertson]

Ok sounds good. I can take a look at it! Thanks for the background.