Onkyo integration fails to connect and then fails to sleep after upgrade to 2024.7

bakerkj commented 4 months ago

The problem

The Onkyo integration is no longer able to connect to my Pioneer receiver in 2024.7. It was able to do so in 2024.6. The receiver is on, pingable, and unchanged. I am suspicious of the new Onkyo driver implementation implemented and merged into 2024.7 here (https://github.com/home-assistant/core/commit/a4ba346dfc1308f8ab961ed151a7865958e945f4).

This is the first error:

    return await fut
           ^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 681, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
ConnectionRefusedError: [Errno 111] Connect call failed ('192.168.9.158', 60128)

In the process of handling that failed exception, it subsequently produces an additional exception:

    await asyncio.sleep(interval, loop=self._loop)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: sleep() got an unexpected keyword argument 'loop'

What version of Home Assistant Core has the issue?

core-2024.7.2

What was the last working version of Home Assistant Core?

core-2024.6

What type of installation are you running?

Home Assistant OS

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

media_player:
  - platform: onkyo
    host: host.domain.org
    name: Receiver

Anything in the logs that might be useful for us?

2024-07-12 19:47:32.148 ERROR (MainThread) [homeassistant.components.media_player] Error while setting up onkyo platform for media_player
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/pyeiscp/connection.py", line 350, in _reconnect
    await self._loop.create_connection(
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1122, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1104, in create_connection
    sock = await self._connect_sock(
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1007, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 641, in sock_connect
    return await fut
           ^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 681, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
ConnectionRefusedError: [Errno 111] Connect call failed ('192.168.9.158', 60128)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in _async_setup_platform
    await asyncio.shield(awaitable)
  File "/usr/src/homeassistant/homeassistant/components/onkyo/media_player.py", line 229, in async_setup_platform
    receiver = await pyeiscp.Connection.create(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/pyeiscp/connection.py", line 188, in create
    await conn._reconnect()
  File "/usr/local/lib/python3.12/site-packages/pyeiscp/connection.py", line 369, in _reconnect
    await asyncio.sleep(interval, loop=self._loop)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: sleep() got an unexpected keyword argument 'loop'

Additional information

No response

home-assistant[bot] commented 4 months 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!

Code owner commands

Code owners of `onkyo` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign onkyo` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

onkyo documentation onkyo source _{^{(message by IssueLinks)}}

arturpragacz commented 4 months ago

There are two issues here. The second is that there is a bug in the library, which prevents it from trying to reconnect to the receiver. The first is that the connection fails in the first place. Make sure that your receiver has active network connection, it should be accessible at IP 192.168.9.158 and should be listening at port 60128.

mtdcr commented 4 months ago

If the receiver is unreachable at any time, the integration should just keep retrying to connect infinitely, because the receiver may have been powered off temporarily (which usually happens multiple times per day for me, and quite often the receiver is off when home assistant restarts).

Bromaynard commented 4 months ago

I have a similar issue with 2024.7.2. everything was working with 2024.6.4, but now my DNLA server works but streaming from radio-browser no longer works after working for quite some time. I even posted my card yaml to share with the community here:

https://community.home-assistant.io/t/radio-browser-how-to-use/398397/53

My AVR displays "now initializing..." on first connect and then becomes unresponsive from HA. after 30s I get a quick_play error...

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:241 
integration: Home Assistant WebSocket API (documentation, issues) 
First occurred: 6:03:57 PM (2 occurrences) 
Last logged: 6:04:00 PM

[547716138176] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 100, in wrapper
    return_value = func(self, *args, **kwargs)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 508, in _quick_play
    quick_play(self._get_chromecast(), app_name, data)
  File "/usr/local/lib/python3.12/site-packages/pychromecast/quick_play.py", line 97, in quick_play
    controller.quick_play(**data, timeout=timeout)
  File "/usr/local/lib/python3.12/site-packages/pychromecast/controllers/media.py", line 559, in quick_play
    response_handler.wait_response()
  File "/usr/local/lib/python3.12/site-packages/pychromecast/response_handler.py", line 54, in wait_response
    raise RequestTimeout(self._request, self._timeout)
pychromecast.error.RequestTimeout: Execution of quick play http://playerservices.streamtheworld.com/api/livestream-redirect/KKJZFMAAC.aac timed out after 30.0 s.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 241, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2731, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2774, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 999, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1071, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 777, in async_play_media
    await self.hass.async_add_executor_job(
  File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/cast/media_player.py", line 102, in wrapper
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: CastMediaPlayerEntity._quick_play Failed: Execution of quick play http://playerservices.streamtheworld.com/api/livestream-redirect/KKJZFMAAC.aac timed out after 30.0 s.

arturpragacz commented 4 months ago

@Bromaynard This is an unrelated issue. In fact, based on the logs you provided, it is not related to the onkyo integration at all, as it references cast integration instead.

Please make a separate issue, as tracking unrelated things in a single issue makes it more confusing.

arturpragacz commented 4 months ago

@mtdcr Yes, that is the goal. Unfortunately, due to a bug in the library, auto reconnect does not currently work. As a workaround you can try to use the network standby, if your receiver supports it.

Bromaynard commented 4 months ago

@Bromaynard This is an unrelated issue. In fact, based on the logs you provided, it is not related to the onkyo integration at all, as it references cast integration instead.

Please make a separate issue, as tracking unrelated things in a single issue makes it more confusing.

@arturpragacz I believe this is an issue with the google cast connecting to the onkyo integration. I can not paste any logs for the onkyo, because it complains about not having a unique ID, so no logs are available. I have a DNLA server that works with the onkyo integration, and radio-browser works in the browser and a ecobee speaker, but it is no longer working with my onkyo.

I can not troubleshoot past the google cast log. The error was similar enough to the above issue, so that is why I commented, but I will try to figure out how to move my comments to a new issue.

bakerkj commented 4 months ago

@mtdcr Yes, that is the goal. Unfortunately, due to a bug in the library, auto reconnect does not currently work. As a workaround you can try to use the network standby, if your receiver supports it.

Thanks @arturpragacz for filing the bug with the upstream library (https://github.com/winterscar/python-eiscp/pull/10).

Fischmuetze commented 3 months ago

Hi, I run in the same problem ... I wonder why for HA before 2024.06 it wasn't necessary that the "onkyo" device is reachable all time via network, but since 2024.6 the integration fires an "Entity not available" if the device is not available during the launch of the integration. This is very, very impractical changed behaviour since my receiver i placed behind a switchable power plug. In consequence I must after launch HA, enable the switchable Plug with HA and then restart HA again ...

Protocol details (Error)

Logger: homeassistant.components.media_player Quelle: helpers/entity_platform.py:364 Integration: Mediaplayer (Dokumentation, Probleme) Erstmals aufgetreten: 20:22:53 (1 Vorkommnisse) Zuletzt protokolliert: 20:22:53

Error while setting up onkyo platform for media_player Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/pyeiscp/connection.py", line 350, in _reconnect await self._loop.create_connection( File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1122, in create_connection raise exceptions[0] File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1104, in create_connection sock = await self._connect_sock( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1007, in _connect_sock await self.sock_connect(sock, address) File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 641, in sock_connect return await fut ^^^^^^^^^ File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 681, in _sock_connect_cb raise OSError(err, f'Connect call failed {address}') OSError: [Errno 113] Connect call failed ('192.168.1.215', 60128)

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in _async_setup_platform await asyncio.shield(awaitable) File "/usr/src/homeassistant/homeassistant/components/onkyo/media_player.py", line 229, in async_setup_platform receiver = await pyeiscp.Connection.create( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/pyeiscp/connection.py", line 188, in create await conn._reconnect() File "/usr/local/lib/python3.12/site-packages/pyeiscp/connection.py", line 369, in _reconnect await asyncio.sleep(interval, loop=self._loop) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: sleep() got an unexpected keyword argument 'loop'

HenningGithub commented 3 months ago

Can the change be reverted until it's ready, meaning, without introducing such a huge regression? Having a AVR offline frequently seems pretty usual to me, and losing control over it has such annoying side effects due to dependent automations that I for one am stuck with 2024.6.4 for the time being, and the number of similarily affected users seems nontrivial to me judging by this and the other PR.

arturpragacz commented 3 months ago

The change will not be reverted.

I am not sure it is that common. I would assume a typical person would just turn it off using the remote, which just puts it in stand-by mode, and not yank it out of the power completely. In my testing the power draw in stand-by is negligible. But if that is what you want to do, I am not here to convince you otherwise, it is a bug and it needs to be fixed.

The PR to the upstream library was already submitted, there is not much more I can do for now.

Fischmuetze commented 3 months ago

@arturpragacz

I would assume a typical person would just turn it off using the remote, which just puts it in stand-by mode, and not yank it out of the power completely. In my testing the power draw in stand-by is negligible.

imho a rather limited view. As this can involve a whole group of devices a power down for such a group could make more than sense. Over the year it isn't negligible to keep such things online in sense of device life time and power consumption. But ok, it depends from your money bag and your understanding of environmental protection by reduce power consumption.

arturpragacz commented 3 months ago

Again, not here to argue, because it is for each individual user to decide how to use their own device.

It's just that my receiver uses <1W in stand-by, so I don't really see the point of completely unplugging it every day after I'm done listening to music and watching movies. I would imagine that also for the device lifetime it is probably worse to constantly cycle power to it like that, than to just keep it online all the time.

But like I said, I'm not gonna tell you guys how to use your devices. As far as this bug is concerned, it is out of my hands, and depends on the upstream maintainer. The only other option would be to completely fork the upstream library, and it is too early for such a radical move.

Fischmuetze commented 3 months ago

It's just that my receiver uses <1W in stand-by, so I don't really see the point of completely unplugging it every day after I'm done listening to music and watching movies. I would imagine that also for the device lifetime it is probably worse to constantly cycle power to it like that, than to just keep it online all the time.

I understand your point of yiew and for a reduced view on a single device I can accept your meaning but e.g. in my case I have linked in my cinema room my receiver with a big TV, different lighting, a DVD/VBlueRay-player etc.. Why should I keep all this things in m<y basement cinema room online if I'm not using that all? But of course I understand that finally solving that is no longer in your hand.

Thank you anyway for your response.

HenningGithub commented 3 months ago

As others mentioned the receiver's standby power draw isn't the only aspect; I have a bunch more that gets powered off together with it as well. The answers here make pretty clear such a setup is everything but uncommon, and in fact, you are telling us how to use our receivers - power off plain doesn't work any more. I don't understand what the big deal of reverting and re-commiting without this huge regression once the upstream lib is fixed is, that's rather simple to do afaict. In the open source projects I am involved with the first requirement of making changes is to not break existing functionality.

arturpragacz commented 3 months ago

The change will not be reverted.

I'm not sure what open source projects you are involved in, because your Github is empty. But in this project we try to balance the needs of all users.

The new library gives huge benefits to all users, the integration is a lot more responsive, the difference is stark enough that going back just feels unusable.

We are also building further changes on what is already here, so going back would reverse all that progress as well.

It is not happening. It is pointless to discuss it further.

mtdcr commented 3 months ago

Given the state of the library (no activity during the last 3 years), reverting to the previous library appears to be the only sensible option.

You should have checked that before. Even if your PR gets in, how is this integration supposed to evolve without a change in maintainership of the library?

Btw., my AVR powers off itself, and it still turns on automatically when HDMI gets active. No need to keep the network connection alive just to waste more energy on standby.

arturpragacz commented 3 months ago

The previous library is maintained at worse level, with over 50 unsolved issues and lingering PRs.

Btw., my AVR powers off itself, and it still turns on automatically when HDMI gets active. No need to keep the network connection alive just to waste more energy on standby.

If you are already using stand-by, then there is literally no reason not to keep the network connection active. It does not use more power in any measurable way.

HenningGithub commented 3 months ago

This Account is solely for the purpose of Home Assistant PRs, I don't want connections drawn. You almost certainly use my code daily and have pretty certainly never experienced breakage with it cause that never made it to releases afaict. I have reverted a couple of times when regressions not caught in testing showed up that couldn't be fixed pretty much right away, and re-committed once these were sorted out.

This isn't just affecting the obviously considerable amount of users who power off their receivers, it also means every network glitch requires a home assistant restart. Not acceptable and not possibly offset by any other advantages in my book.

Fischmuetze commented 3 months ago

it also means every network glitch requires a home assistant restart. Not acceptable and not possibly offset by any other advantages in my book.

That's absolutely right! That happened to me ... thanks Proxmoxx snapshots I'm now back to 2024.6.4 but stuck there now

HenningGithub commented 3 months ago

So is the integration just being left broken now?

Seriously, anything relying on a long-living network connection and not being able to reconnect just isn't usable in the real world; the fact that in this case the target frequently being powered off is somewhat common just makes it even worse. The new library may be the way forward and bring advantages, but until it has the most basic connection handling working it just isn't anywhere near ready to be shipped in a release. It's broken in releases for a month already.

saschaludwig commented 3 months ago

I also have the problem with the Integration now. If I don't use my receiver, I switch off power to all my home-entertainment components to save energy. 🌎 Having the receiver running/powered 24/7 and let it suck standby power isn't an option for me.

In the past, the integration did a reconnect after the receiver was powered up. That's not happening any more. Even worse: If I (re)start home-assistant while the receiver is off, all my automations with the integration fail, because the integration won't properly reconnect. That's a bit unsatisfying.

Is there any workaround? Can the integration be reloaded or restarted?

Carkhass commented 3 months ago

I also have the problem with the Integration now. If I don't use my receiver, I switch off power to all my home-entertainment components to save energy. 🌎 Having the receiver running/powered 24/7 and let it suck standby power isn't an option for me.

In the past, the integration did a reconnect after the receiver was powered up. That's not happening any more. Even worse: If I (re)start home-assistant while the receiver is off, all my automations with the integration fail, because the integration won't properly reconnect. That's a bit unsatisfying.

Is there any workaround? Can the integration be reloaded or restarted?

Same problem with my tx-nr636 :(

arturpragacz commented 3 months ago

Please stop spamming this issue.

You're sending notifications for no reason to all the people watching this thread.

If you have no new information to add, use emojis to react instead.

arturpragacz commented 3 months ago

@home-assistant add-label problem in dependency

Fischmuetze commented 3 months ago

Spam? I like to see that a lot of people have the same issue that obviously is ignoring… see the discussion before Am 20.08.2024 um 01:18 schrieb Artur Pragacz @.***>: Please stop spamming this issue. You're sending notifications for no reason to all the people watching this thread. If you have no new information to add, use emojis to react instead.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

HenningGithub commented 3 months ago

Please finally revert this prematurely commited change and don't leave all onkyo users left out in the rain. "I've filed a PR which hasn't lead to any response in 5 weeks at the upstream project which hasn't seen any activity in 2 years" obviously isn't going anywhere anytime soon. This change can and probably should come back once the most basic connection handling works, as is it has just broken the onkyo integration. Is there really nobody in home assistant who has the guts to revert a broken change? Is 2024.9 going to be the 3rd major release in a row shipping with a broken onkyo integration?

arturpragacz commented 3 months ago

This issue is getting very heated and toxic now, so I'm forced to unsubscribe.

To reiterate once more: the change will not be reverted. It is not up to discussion.

Fischmuetze commented 3 months ago

This issue is getting very heated and toxic now, so I'm forced to unsubscribe.

There is no heated or toxic reaction, except than yours

bakerkj commented 3 months ago

I think we may be able to work around this issue by creating a HACS addon based directly on the original Onkyo Implementation from 2024.6. This would allow everyone who was happy with the old Onkyo integration to use it again while the issues (like this ticket) are fixed in the current built in integration.

I will likely explore this option in a few weeks unless someone else gets to it first.

damocles-dev commented 3 months ago

A user posted a workaround using the REST interface, maybe it can help you while the integration is not complete: https://github.com/home-assistant/core/issues/123143#issuecomment-2282378736

saschaludwig commented 3 months ago

A user posted a workaround using the REST interface, maybe it can help you while the integration is not complete:

As far as I can see, my receiver doesn't have a REST interface.

arturpragacz commented 3 months ago

Now you guys aren't just commenting here, but also cross linking to other issues I'm watching... Not helpful.

@bakerkj If you're gonna run a custom component, then you might just as well run my dev version. That would actually be useful, to see whether the fix works, or are there any other issues.

saschaludwig commented 3 months ago

Maybe this is common knowledge among hacs devs, but I wanted to leave this information here anyway for others not knowing:

If you want to test the dev version of arturpragacz, you can just add the github url https://github.com/arturpragacz/hass-cc-onkyo-dev as a custom HACS repo and then install the "Onkyo dev" integration in HACS.

JayOne73 commented 3 months ago

For people using the state of the onkyo receiver being on or off in automations. You could use the exposed device_tracker entity which is 'home' or 'not_home' depending of the receiver is on or off respectively.

smoltron commented 2 months ago

I am not sure when my Onkyo integration stopped working, but it was after some update in summer. But now, after 2024.9.0, the media player is not found any more at all. No matter if it is on or off. In late summer the integration worked if the receiver (TX-NR818) was on. Now not at all.

arturpragacz commented 2 months ago

@smoltron If there is some new problem, please create a separate issue for it. Provide there all the necessary information (your configuration, debug logs, etc.).

bakerkj commented 2 months ago

Now you guys aren't just commenting here, but also cross linking to other issues I'm watching... Not helpful.

@bakerkj If you're gonna run a custom component, then you might just as well run my dev version. That would actually be useful, to see whether the fix works, or are there any other issues.

Unfortunately, this dev version is not able to communicate with my Pioneer Elite receiver.

bartmarchand1 commented 2 months ago

Same problem with my tx-nr545 :(

arturpragacz commented 2 months ago

There is currently no difference between that repo and what is in core. The only difference is that it includes the fixed library.

mtdcr commented 2 months ago

There is currently no difference between that repo and what is in core. The only difference is that it includes the fixed library.

So we can pretty safely assume that the fixed library is the problem.

I know that this comment doesn't really help.

However, there are no useful messages in my HA log to share with you easily. I will probably have to debug this on my own when I find the time later this year, or just create a custom component based on the old, unfancy working version.

Has anything been decided in the meantime, regarding the fate of the library?

arturpragacz commented 2 months ago

Make sure to enable debug logging. Or do you mean there are no logs with it enabled? That would be pretty weird.

As for the library, as there is no contact from the author, it will have to be replaced. Probably I will write and maintain my own, that is the plan right now. But that will take time. And currently the priority is to get the config flow merged in, as the lack of it effectively prevents adding any new features to the integration.

Ziriaz commented 2 months ago

My Onkyo receiver has a secondary zone and that zone has always had this issue. If the receiver is completely powered off during homeassistant startup then the secondary zone won't connect. After the update it seems that this issue is there for the primary zone as well.

As a workaround I created a script that will turn on the wall plug, delay, restart home assistant and then turn the wall plug off again. I now use this script as a custom button to restart HA.

It's just a workaround but I tought it could be useful to share anyway.

naudster commented 2 months ago

I also hit this problem. For me, enabling network standby is an easy workaround.

Big thanks to @arturpragacz for actively maintaining this integration. It's disappointing you've copped a lot of attitude in this thread. The fact it hasn't dissuaded you from continuing the work is a testament to your professionalism and resilience. 👍

arturpragacz commented 2 months ago

I investigated the recent issues and found a likely cause.

Starting from version 2024.9, we assign unique_id to all created media player entities. This is a long awaited change as it allows users to change the name, icon, area, etc. using the Home Assistant UI.

Unfortunately it also means that we have to interview the receiver prior to creating any entities. Therefore the integration will not work without the receiver being properly connected at all times. Let me remind you that this condition is explicitly mentioned at the very top of the documentation.

That being said, I do plan to also support proper reconnects and receiver going offline, even if it is not a recommended setup. For that to happen though, two things need to be done: first we need to merge the config flow support, and second the library needs to be rewritten. Both of these are big undertakings and may take some significant time before they are finished.

mtdcr commented 2 months ago

For the time being, here's a custom component containing the pre-2024.7 version. Don't expect maintenance or support. https://github.com/mtdcr/homeassistant-onkyo-legacy

andreasfrosig commented 2 months ago

@mtdcr How do i use that one? I have imported it through HACS, but i do not know how to activate it. Is it automatically overwriting the core Onkyo platform, or is there an other name that i need to use?

mtdcr commented 2 months ago

@mtdcr How do i use that one? I have imported it through HACS, but i do not know how to activate it. Is it automatically overwriting the core Onkyo platform, or is there an other name that i need to use?

Yes. Once installed to the custom_components directory, it replaces the core integration and uses the existing configuration. You should see a log entry regarding the custom integration on startup.

bencollinz commented 1 month ago

For the time being, here's a custom component containing the pre-2024.7 version. Don't expect maintenance or support. https://github.com/mtdcr/homeassistant-onkyo-legacy

Thank you very much for this!

bakerkj commented 1 month ago

For the time being, here's a custom component containing the pre-2024.7 version. Don't expect maintenance or support. https://github.com/mtdcr/homeassistant-onkyo-legacy

@mtdcr thank you so much for this. Works like a charm!

home-assistant / core