The timeout you set during setup is just the maximum time the integrations waits for a connection try or response and not a delay. If the receiver answer quickly enough you can send multiple commands in a row. This depends on how long it takes for an answer. If also other commands besides power on take longer to respond that might be a problem with your network or receiver. I thought it is just the Power On command that needs a longer timout? Accoridng to your log for Power off it took the reciver under 1 second for a response.
I could reproduce this behaviour by adding a manual response deplay to my test receiver script. The client blocks new requests until it has sent the response and this results in timeouts on the remote when sending mutliple commands in a row. Reducing the manual delay in the script but keeping the longer timeout works and multiple commands can be sent without a timeout on the remote. I wondering why the Arcam can’t handle multiple threads that would prevent this.
If I set the Advanced Settings - Text over TCP timeout value to 3 seconds it responds consistently (working as it should) like this in the log:
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO ucapi.api DEBUG [(‘127.0.0.1’, 52702)] ->: {‘kind’: ‘resp’, ‘req_id’: 49, ‘code’: 200, ‘msg’: ‘result’, ‘msg_data’: {}}
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO Sky Stream
2025-10-05 17:25:47.102765 +00:00 custom-intg-requests INFO commands INFO Received data: !(
2025-10-05 17:25:47.101596 +00:00 custom-intg-requests INFO commands INFO Sent raw text ‘raw=0x21 0x01 0x08 0x02 0x10 0x20 0x0D’ over TCP to 10.1.0.151:50000
2025-10-05 17:25:47.002324 +00:00 custom-intg-requests INFO remote DEBUG Executing command MODE
2025-10-05 17:25:46.998883 +00:00 custom-intg-requests INFO config DEBUG Get variables from _vars block in custom entities yaml configuration
2025-10-05 17:25:46.856434 +00:00 custom-intg-requests INFO remote INFO Received send_cmd command with parameter {‘command’: ‘MODE’} for entity id remote-custom-arcam-avr30-ip
2025-10-05 17:25:46.856061 +00:00 custom-intg-requests INFO ucapi.api DEBUG [(‘127.0.0.1’, 52702)] <-: {“kind”:“req”,“id”:49,“msg”:“entity_command”,“msg_data”:{“cmd_id”:“send_cmd”,“entity_id”:“remote-custom-arcam-avr30-ip”,“entity_type”:“remote”,“params”:{“command”:“MODE”}}}
As soon as I increase the timeout value to 6 seconds to resolve the Power On timeout issue, this is logged and it no longer responds to multiple presses:
2025-10-05 17:22:44.332243 +00:00 custom-intg-requests INFO ucapi.api DEBUG [(‘127.0.0.1’, 52702)] ->: {‘kind’: ‘resp’, ‘req_id’: 30, ‘code’: 408, ‘msg’: ‘result’, ‘msg_data’: {}}
2025-10-05 17:22:44.327320 +00:00 custom-intg-requests INFO commands WARNING Timeout while waiting for a response message from the server
2025-10-05 17:22:38.319566 +00:00 custom-intg-requests INFO remote DEBUG Executing command MODE
2025-10-05 17:22:38.315740 +00:00 custom-intg-requests INFO config DEBUG Get variables from _vars block in custom entities yaml configuration
2025-10-05 17:22:38.139517 +00:00 custom-intg-requests INFO remote INFO Received send_cmd command with parameter {‘command’: ‘MODE’} for entity id remote-custom-arcam-avr30-ip
2025-10-05 17:22:38.139238 +00:00 custom-intg-requests INFO ucapi.api DEBUG [(‘127.0.0.1’, 52702)] <-: {“kind”:“req”,“id”:30,“msg”:“entity_command”,“msg_data”:{“cmd_id”:“send_cmd”,“entity_id”:“remote-custom-arcam-avr30-ip”,“entity_type”:“remote”,“params”:{“command”:“MODE”}}}
I suspect there is something in your network that occasionally slows down the response of the receiver. Technically speaking, it makes no sense that the timeout has an effect on the receiver’s response speed.
It’s an odd issue, but I feel it’s probably related to the Arcam. It’s strange that a TCP timeout of under 4 seconds results in all commands working except Power On, then the reverse is true if it’s set to over 4 seconds. The remote, dock and AVR are all directly connected to a 2.5Gb layer 3 Unifi switch, same VLAN etc. I’ve taken packet captures and don’t see any network related delays.
I released a new version that adds a commands specific timeout parameter: Release v0.8.6 · kennymc-c/ucr2-integration-requests · GitHub
This is brilliant solution, thank you so much for your time and updates to get this working, much appreciated. It’s now working perfectly as far as I can tell!
If you have Home Assistant, you can use the Arcam integration there to control your AVR from the remote. Works like a charm on my AV41.