kongo09 / hass-onkyo-ng

Better support for Onkyo devices in Home Assistant
Apache License 2.0
7 stars 2 forks source link

No zone 2 #3

Open dannytrigo opened 7 months ago

dannytrigo commented 7 months ago

I was expecting to get a zone 2 media player entity with this integration but it doesn’t seem to create one. I can look into implementing that if it’s not currently supported

kongo09 commented 7 months ago

It's currently just experimental

dannytrigo commented 7 months ago

Work ongoing - just a draft for now but the basics work: https://github.com/kongo09/hass-onkyo-ng/pull/4

dannytrigo commented 6 months ago

I've sent a few incremental PRs for this but once https://github.com/kongo09/hass-onkyo-ng/pull/6 is merged it adds support for multiple zones. Everything is still handled over a single TCP connection to the receiver, but the commands are sent asynchronously and state updates are processed as they're received rather than by polling.

kongo09 commented 6 months ago

Thanks for spending time on this!

kongo09 commented 6 months ago

@dannytrigo : I merged your PRs but this doesn't work on my Onkyo:

This error originated from a custom integration.

Logger: root
Source: custom_components/hass_onkyo_ng/onkyo.py:113
integration: Onkyo AV Receiver (documentation, issues)
First occurred: 23:14:30 (3 occurrences)
Last logged: 23:18:34

Uncaught thread exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.12/threading.py", line 1010, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.12/site-packages/eiscp/core.py", line 562, in _thread_loop
  File "/usr/local/lib/python3.12/site-packages/eiscp/core.py", line 552, in trigger
  File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 29, in <lambda>
    self._receiver.on_message = lambda msg: self._on_message_async(msg)
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 113, in _on_message_async
    message_decoded = iscp_to_command(message, with_zone=True)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: iscp_to_command() got an unexpected keyword argument 'with_zone'
kongo09 commented 6 months ago

After some reboot, I now get:

File "/config/custom_components/hass_onkyo_ng/config_flow.py", line 93, in async_step_user
onkyo_receiver = OnkyoReceiver(host, hass=None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 67, in __init__
self.command_sync('dock.receiver-information=query')
File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 302, in command_sync
result_raw = self.raw_sync(raw_command)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 289, in raw_sync
raise ValueError("Timeout waiting for response")
ValueError: Timeout waiting for response
dannytrigo commented 6 months ago

For the first error, that’s a new parameter I added in my fork of onkyo-eiscp. It’s referenced in the manifest so it should be picked up and installed by homeassistant.

For the second one, are you running any other home assistant instance on the same host, or anything else interacting with the receiver? I’ve found that mine will only allow one connection per IP and keeps disconnecting other connections leading to timeouts waiting for responses like that.

kongo09 commented 6 months ago

Nothing else on that host communicates with the Onkyo

dannytrigo commented 6 months ago

Can you try with the latest PR and with debug logs and see if there is a disconnection after sending the command? That PR also adds 3 retries

I hope that command is supported by all models, I’m pretty sure that’s how the mobile app must get the source list

dannytrigo commented 6 months ago

@kongo09 let me know if the current version of the integration is working for you. It's pretty stable for me now. Also, happy to close this issue, but I have no other way to contact you :)

kongo09 commented 6 months ago

I still cannot setup my device:

File "/config/custom_components/hass_onkyo_ng/config_flow.py", line 89, in async_step_user
info = onkyo_receiver.receiver_info
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 139, in receiver_info
self.command_sync('dock.receiver-information=query')
File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 335, in command_sync
result_raw = self.raw_sync(raw_command)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/hass_onkyo_ng/onkyo.py", line 322, in raw_sync
raise ValueError("Timeout waiting for response")
ValueError: Timeout waiting for response
dannytrigo commented 6 months ago

I can only assume your receiver model doesn’t support that command. I believe it’s NRIQSTN. I saw the Onkyo app also sends MDIQSTN which gives a smaller XML with less detail. Maybe certain receivers only support that one.

What model do you have? Is it multi zone? Would you be willing to run some python code to collect the responses to certain commands so I can fix it for your case? I can prepare the commands, or a python script to run them and output the responses

kongo09 commented 6 months ago

Where did you find this command documented. I cannot see it in the eiscp documentation? I have TX-NR616

kongo09 commented 6 months ago

Screenshot_20240329-000011

My device doesn't support this command

dannytrigo commented 6 months ago

Thanks, I’ll rework what I’ve done to only use that command if available

dannytrigo commented 6 months ago

https://github.com/kongo09/hass-onkyo-ng/pull/12 should now hopefully support your receiver. If you receiver doesn't support the MDI command that is now used, I can rework that too.

I am curious though - when you use the Onkyo smartphone app, what sources does it display? I am wondering how it determines that info, unless its hardcoded in the app based on model ID.

kongo09 commented 6 months ago

That's why I had the automatic source crawling in the integration, just looping through the sources to identify what is available. I guess the smartphone app uses a simple lookup table, which in fact would also be the most simple alternative for the integration as all combinations are known.

I'll try later.

dannytrigo commented 6 months ago

I've sent one more PR on this topic. This one should now only need the UDP response for info that your original had, so I'm 99% sure it should now work for you.

I agree a hardcoded mapping might be best. The problem with going through all the sources at config time was that it would get even slower for multiple zones (as each zone supports a different set of sources)