Change Listening mode of media player

Add a key in manifest.json

 "version": "5"
}

Any random number will do.

If you have other custom integrations, they all have a manifest.json with a version key.

I need this for my home as well, along with audyssey-dynamic-volume. I used to control my AVR with MQTT, but this would be much better. Since @koying is silent since 2 years, I assume he/she is not going to offer it as a PR, so I might take a swing. Any objections there?

1 Like

To offer a pr I think you’ll need to add gui configuration.

A custom component may be easier to manage.

1 Like

I like a challenge, and I’d like to contribute so thats fine with me. I was thinking of making the interface to the python library thinner, so that a simple yaml block could match the eiscp command, and a dictionary could map on to values like so:

eiscp:
  listening-mode:
    name: Sound mode
    options:
      pure-audio: normal listening
      theatre-dimensional: movies

That way all of the library could be supported without dubbing everything in the integration.

Little status update: got it working this far, including manual setup and manual discovery (my receiver is too old for Bonjour)

I need to implement some data updates and re-enable zones, then create unit-tests. I’ll put up a PR for it to be merged once I’m done.

2 Likes

Happy to test it you have something to share.

1 Like

Appreciated! What would be your preferred way of sharing the integration? It is on my github, but I don’t know how “custom”/beta integrations are typically shared.

Point me to your GitHub. I may be able to figure it out.

Sure thing: GitHub - Nebula83/core at update-onkyo-integration

I’m pretty much done except for additional zones. That should be fairly straightforward, so I expect to finish up functional code this week.

Scratch that, I killed something in the last refactor. I’ll post back later when I find the issue.

I’m losing messages over the additional channels, so that would imply using a coordinator. The changeset is already quite big, so I decided to ditch the customizable channels for now. I did add a onkyo command service, so no functionality is really lost.

I still need to add additional zones, but the current status should be ready for testing :+1:

1 Like

Feature complete. Now writing the required for unit-tests. Testing is appreciated :slight_smile:

PR is here: Update onkyo integration by Nebula83 · Pull Request #117319 · home-assistant/core · GitHub

1 Like

I am unable to get it to work. I’m on my tablet and will post logs when I’m on a proper computer.

(Sorry I completely forget about testing this)

1 Like

Hi there, I was able to get your PR working on my production Home Assistant (2024.5.3) as a custom component connected to my Onkyo TX-NR575E. Below are a few observations I made.

Just adding the Onkyo directory to my custom_components folder (and adding the version in the manifest.json) didn’t work for me. Onkyo did not appear Add Integration list. I found a developer doc advising to run hassfest script in order to force update the config_flow: true from the manifest.json file. However I’m not running a developer environment and didn’t have the script so I ended up renaming the domain to onkyo_nebula in the manifest.json, services.yaml and const.py files.

I have two other Onkyo custom components installed from other developers which could have been causing conflicts:

  • foxy82’s async Onkyo integration has been running for around a year. It has been fast and reliable, but does not support unique_ids.
  • klaashoekstra94’s PR was previously running, but eventually it stopped working after changes were made to Core async_setup_platforms requirements.

In any case, once I renamed the domain it appeared in the Add Integration list and I was able to proceed through the config_flow. I ran into a couple of issues, which were not showstoppers:

  • The IP address and Port fields names were missing. Maybe something went wrong because of me renaming the domain?
  • After entering the IP and port, I got “Unknown Error Occurred”. But on second attempt with same info it worked fine. Maybe because I still have my old Onkyo integration configured?
  • The options flow wasn’t automatically launched. Maybe that is expected?
  • Clicking on the config_entry’s Configure button I was able to launch the options_flow. Again, all of the field names were missing, but I was able to configure all of the sources I use and all of the sound_modes that my receiver supports.
  • The max volume option’s didn’t suit my receiver, mine goes up to 96, so it meant the volume number didn’t match exactly (minor issue).

Once configured I tested the below options on the media_player which all worked fast and reliably:
Power on/off, mute/unmute, vol up/down, setting specific volume (worked but didn’t match), setting all 9 source options, setting all 17 sound modes.

When controlling my receiver physically, the media_player entity updated correctly for all sources and sound modes. I noticed that it was about 4-5 slower than the foxy82 integration, which updated instantly.

Lastly, I just wanted to thank you for your work on this. The Onkyo integration really needs a refresh, and I think your work will benefit many people. I’m more than happy to help out with any testing! Cheers!

1 Like

No problem, let me know what you run into.

Hi there, I was able to get your PR working on my production Home Assistant (2024.5.3) as a custom component connected to my Onkyo TX-NR575E. Below are a few observations I made.

Awesome! Thanks for your time.

Just adding the Onkyo directory to my custom_components folder (and adding the version in the manifest.json) didn’t work for me. Onkyo did not appear Add Integration list. I found a developer doc advising to run hassfest script in order to force update the config_flow: true from the manifest.json file. However I’m not running a developer environment and didn’t have the script so I ended up renaming the domain to onkyo_nebula in the manifest.json, services.yaml and const.py files.

Yeah, since this aims to replace the official one, you need to jump through some hoops to get it to work. I just replaced the official integration, but that might not be for everyone. Indeed you need to run python3 -m script.hassfest to update your integrations. Then you need to run python3 -m script.translations develop --integration onkyo_nebula to update translations.

[snip]

In any case, once I renamed the domain it appeared in the Add Integration list and I was able to proceed through the config_flow. I ran into a couple of issues, which were not showstoppers:

  • The IP address and Port fields names were missing. Maybe something went wrong because of me renaming the domain?

This is due to missing translations. Running the above mentioned script should fix that.

  • After entering the IP and port, I got “Unknown Error Occurred”. But on second attempt with same info it worked fine. Maybe because I still have my old Onkyo integration configured?

Could be? That doesn’t sound familiar, and I added and removed it a bunch of times during testing :sweat_smile: That was on a clear installation though.

  • The options flow wasn’t automatically launched. Maybe that is expected?

Yes, that’s how it’s set up right now. Would it be better to present that right away? I’m still on the fence.

  • Clicking on the config_entry’s Configure button I was able to launch the options_flow. Again, all of the field names were missing, but I was able to configure all of the sources I use and all of the sound_modes that my receiver supports.

Missing translations again indeed.

  • The max volume option’s didn’t suit my receiver, mine goes up to 96, so it meant the volume number didn’t match exactly (minor issue).

I assumed that the information on the Onkyo doc page was correct. It seems that needs to be a number instead of a radio button as well. What a weird value though, 96.

Once configured I tested the below options on the media_player which all worked fast and reliably:
Power on/off, mute/unmute, vol up/down, setting specific volume (worked but didn’t match), setting all 9 source options, setting all 17 sound modes.

Awesome!

When controlling my receiver physically, the media_player entity updated correctly for all sources and sound modes. I noticed that it was about 4-5 slower than the foxy82 integration, which updated instantly.

Yes, that’s because I (and the original integration) use polling exclusively. The foxy82 uses push-semantics. This would involve a rather big change in the codebase though, so I’m saving that for another PR.

Lastly, I just wanted to thank you for your work on this. The Onkyo integration really needs a refresh, and I think your work will benefit many people. I’m more than happy to help out with any testing! Cheers!

Thank you very much! Thank you for providing me with invaluable feedback!

1 Like

Review is live. All new stuff needs to be dropped, so iteration one will be slightly boring :-p

No worries, happy to help!

Yeah, since this aims to replace the official one, you need to jump through some hoops to get it to work. I just replaced the official integration, but that might not be for everyone. Indeed you need to run python3 -m script.hassfest to update your integrations. Then you need to run python3 -m script.translations develop --integration onkyo_nebula to update translations.

These scripts weren’t installed natively on my instance. Do you know if I need to setup a full developer environment, or is there some other way to get these scripts (and any pre-requisites) installed?

This is due to missing translations. Running the above mentioned script should fix that.

That makes sense, cheers!

Could be? That doesn’t sound familiar, and I added and removed it a bunch of times during testing :sweat_smile: That was on a clear installation though.

Sounds like it was probably just a one off error for me. Will report back if I get it again.

Yes, that’s how it’s set up right now. Would it be better to present that right away? I’m still on the fence.

I think it would be nice to present it right away. You could also add a description in the prompt that they can return to these options later if required.

Does the underlying library and API allow you to get the configured custom names from the receiver? For example, my receiver is setup with input strm-box to be displayed as Chromecast. Could we pull that info? Also, can we pull the available sound modes from the receiver? These are more ideas for later PRs if you’re interested.

I assumed that the information on the Onkyo doc page was correct. It seems that needs to be a number instead of a radio button as well. What a weird value though, 96.

Yeah it is weird. The receiver actually goes 95, then “MAX”. Looking at my configuration on the foxy82 implementation, I actually use the key/value max_volume: 100. Despite mine only going to 96, this doesn’t apply any scaling and the volume values match between the entity and the receiver. I just tested setting 100 on the entity, and it applies 96/MAX on the receiver.

Yes, that’s because I (and the original integration) use polling exclusively. The foxy82 uses push-semantics. This would involve a rather big change in the codebase though, so I’m saving that for another PR.

That makes sense, and is a great idea to save it. I think one of the main downfalls of the last attempt to update the integration, was that the PR was so large it was hard to review. The other issues seemed to be that there is no code owner for Onkyo, and reviewers did not like to get @ pinged, so that might have pushed it back in the queue. I can see on your PR you’ve already got some buy in so that is good news!

Thank you very much! Thank you for providing me with invaluable feedback!

Glad to help! Would it be worth while testing your most recent changes? And/or waiting to test the yaml import?

1 Like

I guess? You can also just patch the relevant files in homeassistant/generated. Translations are a little tougher, I don’t know of an alternative.

I’ll take it along as an improvement on the current PR, limiting size is the name of the game right now. It still amounts to some 1000 changed lines :-o

I didn’t even know you could change that in the Receiver lol! I haven’t found a way to find available… anything… from the receiver. It seems you need to know what you want to set up.

[quote=“Deez, post:77, topic:403733”]
Yeah it is weird. The receiver actually goes 95, then “MAX”. Looking at my configuration on the foxy82 implementation, I actually use the key/value max_volume: 100. Despite mine only going to 96, this doesn’t apply any scaling and the volume values match between the entity and the receiver. I just tested setting 100 on the entity, and it applies 96/MAX on the receiver.
[/onkyo]
The current implementation allows for a value between 80 and 200 in steps of one. Then it should always just work.

Fingers crossed!

I just finished up importing, so by all means, have a go. I think you need to update the domain of your yaml to onkyo_nebula in your case, but then it should all work automatically. Pretty neat feature HA has in the framework.

1 Like

I bit the bullet and just setup a devcontainer dev environment using your update-onkyo-integration branch.

I found that I actually needed receiver_max_volume: 100 (not the max_volume key, nor 96 as I had stated previously.

I added the YAML configuration and it was all imported successfully. All the tests I ran before (other than the sound-mode) all worked again.

I did find that the media_player flapped between available and unavailable a few times. I think that might have been my prod and dev instances (running on different machines) fighting over control. Will disable prod, monitor and report back.

I disabled my prod instance’s Onkyo integration 4 hours ago, and Dev has been stable since then, so I think that confirms the reason for the flapping. PR looks good!

1 Like