Open damocles-dev opened 1 month ago
Hey there @arturpragacz, mind taking a look at this issue as it has been labeled with an integration (onkyo
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
onkyo documentation onkyo source (message by IssueLinks)
Using any kind of external command like that is not and never was a supported use case.
Onkyo integration allows you to perform basic operations, if you need to do any other operation such as getting the internal temperature or making adjustments to bass, treble, subwoofer, listening modes, etc., the CLI command is used.
Things like that should be supported in the integration itself, in the form of additional sensors and services. There is a plan to extend the integration to support those use cases, but we first need to migrate it to config flow. Using any external executable, especially running on the same host, is the very wrong way to do this.
That being said, I will keep this issue open for now, because there is unfortunately also a more general problem with receiver not properly staying connected and having more logs is always good for troubleshooting. It would be good if you could post the packets from the time the integration gets confused about the input from external command and also from the time it is being constantly reconnected. Also, if you can, please mention what exact receiver model you are using.
It would certainly be the best option to be able to control the extended functionalities using hass but for years the only option was to use commands via cli and right now it is impossible.
The avr is the current mid-range one for home theater: TX-NR6100
I incorporate the logs of a hass execution and a loop of operations that causes reconnections in the communication between the avr and hass.
If multiple operations are issued these accumulate and keep the avr busy sending the responses to hass over several seconds and during these responses hass is unable to correctly perform other operations.
the following logs are the result of the following command: watch -n .2 onkyo --host avr main.system-power=query
the times in the hass logs and in the captures are aligned and you can see how once the sending is finished it continues receiving updates. home-assistant_onkyo_debug_log.txt ha_onkyo.pcap.zip
I have a TX-NR6050. For a couple years now I've also ran unsupported actions using
shell_command:
onkyo_command: onkyo --host 10.0.0.5 {{ cmd }}
and then using it with a separate script call such as:
script:
receiver_lr_quick_menu:
alias: Receiver LR quick menu
sequence:
- service: shell_command.onkyo_command
data:
cmd: OSDQUICK
This worked fine, I know it isn't the intended use case but the functionality I needed wasn't there. Similar to others, this functionality broke after around the 2024.07 update.
After seeing the discussions, I decided to poke around and try an alternative solution. I know the receiver has a new (or new-to-me) UI at http://10.0.0.5/websetup.htm. After inspecting the web requests, I noticed there is a direct API you can call to pass in the lower level ISCP command you want: http://10.0.0.5/iscp_req.cgi?iscp=!1{command}
. For example, to get audio info: http://10.0.0.5/iscp_req.cgi?iscp=!1IFAQSTN. The only requirement is to add the header Authorization: Bearer {base64 encoded version of username:password}
.
Knowing that, I updated my existing sensors/scripts to use this. It doesn't seem to be impacted by having the HA onkyo integration still enabled, and Update: Using the API does seem to break the onkyo
integration. To adjust for this, I updated my code sample below to use a "Universal Media Player" and added commands for power on/off, volume up/down/mute.
From my testing, the API is actually much faster than using the older shell_command action (example at top).
I've included a snippet of my code below, in hopes that this saves time for someone. I look forward to the next phase of this integration so this level of manual setup isn't necessary anymore. In the meantime, the below code can help bridge the gap until we get there for anyone else that was impacted by this change.
The problem
Hello,
Since the update to 2024.07, if any command is executed without being with hass, it can cause communication failures between hass and the avr.
When hass starts, it makes a tcp connection to port 60128 that it keeps open to communicate with the avr.
If any command is executed to the avr with another app such the onkyo python package, the avr ends the communication with hass and performs the communication for the operation that was just sent to it.
So if hass performs any operation afterwards, a new connection is established with the avr.
When the integration used poll, sending concurrent commands did not affect any of the operations, but when communication is done with push, the external application is not able to communicate with the avr and, in addition, the connection between hass and the avr may fail and not be able to communicate with it.
Onkyo integration allows you to perform basic operations, if you need to do any other operation such as getting the internal temperature or making adjustments to bass, treble, subwoofer, listening modes, etc., the CLI command is used.
In the following fragment with 2024.06 you can see that a connection is started in packet 47 and in the relative time we see that at 10 second intervals it performs the poll which would be packets 55 and 63.
Note: host .7 is hass and host .8 is the avr
for this poll the log shows:
If I now run a command for e.g. get temperature:
we see that the avr closes the connection it had with hass in packet 102 and closes the new connection in packets 106 and 107:
now the next poll comes and since the connection was previously closed it needs to open a new one in packet 122:
this new connection is registered by hass:
we were able to run a command and hass recovers without problem.
With 2024.07 and the change from poll to push the following occurs.
A lot more information is sent starting with packet 1 up to 87:
in this case the connection remains busy for a few seconds:
if we now run command by cli we get:
and the information requested by cli is passed to hass as callback at "21:46:16.186":
the problem is not only that the command does not work for us to perform the operations that hass does not perform natively but that executing it can confuse hass and be unable to use the avr for a period of time.
in fact if you run the command a few times it performs a DoS and hass takes several seconds to regain control:
I don't know if it's possible to be able to run commands to make adjustments that hass can't do directly, this integration was the reason I started using hass and it would be desirable not to lose this functionality.
What version of Home Assistant Core has the issue?
core-2024.7.4
What was the last working version of Home Assistant Core?
core-2024.6.4
What type of installation are you running?
Home Assistant Core
Integration causing the issue
onkyo
Link to integration documentation on our website
https://www.home-assistant.io/integrations/onkyo/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response