Onkyo: volume control fixes

[rsmeral]

Description:

Two fixes for Onkyo media player:

• Added support for volume steps
  • the underlying library directly supports it and translates to a receiver-native single unit of volume
  • without this fix, volume up/down is subject to the default media_player behaviour of stepping by 10% which seems too coarse for most receivers
• Serialized command execution to prevent connection errors
  • for example, when the volume_up (or any other) service was called repeatedly in a very fast succession (e.g. when pressing a button on a remote), I'd frequently get a Resetting connection... error
  • this happened most likely because the next command was sent to the receiver before the response from the first one was received
  • this fix corrects that by introducing a queue for service calls (using ThreadPoolExecutor with a single worker)

Disclaimer: I'm not much of a pythonista. Tried running tests, got:

Results (236.02s):
    3540 passed
     100 skipped

But also:

ERROR:   lint: commands failed
ERROR:   typing: commands failed

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

[homeassistant]

Hi @rsmeral,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[houndci-bot]

line too long (88 > 79 characters)

[houndci-bot]

line too long (97 > 79 characters)

[balloob]

Oh no. This is waaay too heavy of a solution. If you would want 1 thread, you should start just a thread, not introduce a whole pool. However, even a thread is not allowed to be added. Imagine all our integrations include a thread, we would swamp the CPU.

So instead, you should use asyncio and locks (Home Assistant core is based on asyncio). Asyncio tasks waiting for a lock don't take up any resources. It means that you need to convert all commands to their async variant and include the lock. Once lock has been acquired asynchronously, use the built-in worker pool to run a threaded command: await hass.async_add_job(self.execute_command, command).

[rsmeral]

Thanks for review. Good point, I'll try to rework.

If the other commit (SUPPORT_VOLUME_STEP) looks OK, I'll make it a separate PR.

[balloob]

Yeah that one is fine.

[andrey-git]

@rsmeral Any updates on this PR?

[rsmeral]

@andrey-git One part got merged (#14299), but the second part (command serialization) I didn't find the time for yet – I agree with the approach proposed by @balloob, but it's non-trivial for me to implement given my limited experience with Python.

[balloob]

This PR seems to have gone stale. Closing it. You can reopen it when you're ready to finish it.