Add support for versioned methods used by newer devices

[allistermaguire]

I have a Sony STR-AN1000 which isn't fully supported. This PR adds support.

Updated to allow the support of multiple API method versions returned by getMethodTypes. It will also check if the version currently being used is a specifically supported version (getSupportedApiInfo) for the device and log a debug message if not.

Adds support for the following specific API Methods

• version 1.2 for getCurrentExternalTerminalsStatus. Includes what should be a non-breaking change for notifyPlayingContentInfo notification.
• version 1.3 for getSourceList.

Update method parameters for the following, as newer devices can be stricter with the API spec. Should be non-breaking.

• getCustomEqualizerSettings.
• getSpeakerSettings.

Limited backward compatibility testing has been done with a STR-DN1080.

Conversation can be found #130

[rytilahti]

Thanks for the PR, @allistermaguire! I don't currently have much time to go through this PR, but I thought it'd make sense to provide some very brief feedback. I'll try and see if my old soundbar still boots and give it a quick test, hopefully some point during the upcoming weekend.

[rytilahti]

Looking good, just a few code readability improvements & one open question wrt get_supported_methods and then this is good to go! 👍

Maybe this debug message could be improved to include the version number (or maybe simply print out method instead of method name which makes those visible):

DEBUG:songpal.service:getSystemInformation got called with args (()) kwargs ({})

I see it's available when raising the verbosity (-dd), but it would be useful to have it shown in the regular debug logs just in case.

[rytilahti]

LGTM after that one nit is done, thanks again for the PR! 🥇

[allistermaguire]

Done I think. Thank you for your patience :)

[rytilahti]

Nah, thanks for your contribution and patience! Although I don't use this myself anymore, it's nice to see improvements that can help others :-)

Do you want to have a new release right away, or do you have some other changes you'd like to get in before I prepare a release with this PR included?

[allistermaguire]

Thanks.

I would like to make it so that all sources (lack of a better term) are available in Hass. At the moment it is only inputs, so missing sources like Spotify, AirPlay, ChromeCast, Tunner etc.

I am not sure where the line is to do it front or back end? There are object differences between get_inputs() and get_source_list(), some URI query string handling with notifications is also necessary.

[rytilahti]

Good question, I'm not sure.. Maybe rather on the homeassistant's side, as that would perhaps make it cleaner to implement zone support, given a single input can be assigned to a single media player?

[allistermaguire]

I had a quick look over the weekend and I think you are right. I was looking to see if it made sense / possible to use a parent class for Source and Input to inherit, but it would need some wiring in the Source child, and what would it be called :)

So I don't have any other changes in the works, so if you could release a new version that would be great. Will you bump it in Hass? If you do can you add _attr_device_class = MediaPlayerDeviceClass.RECEIVER to media_player.py as well.?

[rytilahti]

Okay, new release is now and and I created home-assistant/core#103561 to bump the version. I'll add the device class, let's see if it's okay to do as a part of the version bump or if a separate PR is required :-)