qBittorrent Does Not Refresh After Connection Failure

[Colorado4Wheeler]

The problem

if qBittorrent becomes unavailable, the system no longer tries to reach it and stays in a perpetual state of "unavailable" with no further status updates. The log reports "Connection lost" even though the server is back up again.

To reproduce: quit qBittorrent so that the sensor shows it as unavailable, then bring it back up again. In my case, I restarted qBittorrent at 9:43am and by 10:15am it is still unavailable and the sensor shows a last changed of 9:43am, with logs after that continuing to say it is unavailable.

The only way to get the sensor to connect again is to restart HA.

What is version of Home Assistant Core has the issue?

2021.3.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

qbittorrent

Link to integration documentation on our website

https://www.home-assistant.io/integrations/qbittorrent/

Example YAML snippet

# Put your YAML below this line

Anything in the logs that might be useful for us?

# Put your logs below this line
2021-03-20 09:57:16 ERROR (SyncWorker_8) [homeassistant.components.qbittorrent.sensor] Connection lost
2021-03-20 09:57:16 ERROR (SyncWorker_7) [homeassistant.components.qbittorrent.sensor] Connection lost
2021-03-20 09:57:16 ERROR (SyncWorker_6) [homeassistant.components.qbittorrent.sensor] Connection lost

[probot-home-assistant]

Hey there @geoffreylagaisse, mind taking a look at this issue as its been labeled with an integration (qbittorrent) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[geoffreylagaisse]

I've tested this scenario in my open PR where I've updated the integration to the UI config flow.
The connection seems to resume when the qbittorrent server is working again.
#45618

[mastakebob]

Can confirm this issue still exists as of core-2021.4.5.

Restarting my qbittorrent container causes the qbittorrent sensor to go 'unavailable', and the following log to repeat:

Logger: homeassistant.components.qbittorrent.sensor
Source: components/qbittorrent/sensor.py:113
Integration: qbittorrent (documentation, issues)
First occurred: 7:56:01 AM (732 occurrences)
Last logged: 9:57:30 AM

Connection lost

That's 732 occurrences in just over 2 hours. My qbittorrent has been up since 7:56am.

Only way to get the sensor back and the logs to stop repeating is to restart the HA service.

Is there a way to get the integration to restart its connection to the qbittorrent server if the connection is lost?

[Colorado4Wheeler]

Yes, it is still happening to me as well. In regards to #45618 that @geoffreylagaisse mentioned, I have had it hit and miss reconnect but the earliest I have seen it reconnect is 12+ hours after the disconnect. This also happens if qBittorrent "hangs" for a moment (as it can when it's processing a lot of new items), it will cause the HA integration to see it as a disconnect.

[geoffreylagaisse]

hmm that seems to be the standard polling interval if a device becomes unavailable. I'll take a look at it @Colorado4Wheeler. I'll also update the PR so it passes the checks again. Thanks for testing!

[Colorado4Wheeler]

I think until this behaves a bit more I'm going to remove the integration but will re-install it once a possible fix comes out so I can properly test it. It's causing my logs to completely blow up. In any given day I get between 4,000 and 6,000 errors in my HA logs from this even though my qbT runs 24/7 with occasional pauses or program hangs that then cause HA to spiral out of control.

The error logging seems over-the-top. Perhaps that could be dialed down a few thousand notches? LOL. One possibility might be to log it once per hour to let me know it's down and "further log messages will be suppressed for 60 minutes or until the service is available", but even just a log message once it goes down and one when it comes back up again. This level of logging would be OK if it would detect when it comes back online in less than a day, but since it doesn't it is just so many error messages. Of 8,000 lines of logs in one day for everything that HA is doing, having 50% of it just qbT errors is a lot.

[atxbyea]

This happens to me too, it has been like that forever and will only reconnect on HA restarts.
Happened with qbittorrent in a freebsd jail and running in a docker container, so seems overall to sit on the HA side.
Currently running 2021.04.1, if I restart my qbittorrent container the connection will vanish from HA and not resume until a restart of HA.

[asifma]

Same problem here...

[geoffreylagaisse]

yeah well, I'm still waiting on feedback on my PR ... If that comes a lot of your issues will be fixed

[geoffreylagaisse]

Well I'm sure that Home assistant management has some other pressing issues :-). And I'm pretty sure they have some sort of checklist or procedure or roadmap they follow while testing/approving an integration. That process takes time, I guess.

[Colorado4Wheeler]

It is what it is. I know people get busy and if the bottleneck is the HA main devs need to review the code, then I understand that it will take a bit of time. I disabled it after the logs were just filling up and figure I'll re-enable it if and when it gets fixed. Having QBT on my Home Assistant isn't the most important aspect of my home automation, just a nice thing to have.

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[geoffreylagaisse]

issue is not stale. As long as my config flow PR isn't resolved this issue has to remain open

[NickolaosC]

I am on version 2021.9.7 and this is still occurring.

[snp88]

Issue still persist on 2021.10.6

[ihor-chaban]

The same on 2021.11.2

[si458]

still exits in 2021.11.5, please update to the config flow ui!

[ReenigneArcher]

How about putting this in HACS instead of relying on the core team?

[HA-Roberto]

Still seeing the issue in 2022.6.7

It used to crash my HA instance but it seems to at least not do that anymore.. not sure if that was fixed intentionally... It's still annoying to have to restart HA to get the qbittorrent connection back up and to prevent over 3000 errors to fill up my logs from failed connection attempts that happen overnight.

Seems like the PR was marked as closed due to inactivity. @geoffreylagaisse

[martinrevert]

issue is not stale. As long as my config flow PR isn't resolved this issue has to remain open

Well, the PR 45618 went closed because core reviewers requested changes on January 2022 and by June 2022 you didn't respond @geoffreylagaisse . You don't have any open PR now and this changes can't reach production. Are you still the mantainer of this or can we inform to the core project that this integration is abandoned?

[geoffreylagaisse]

I am still the maintainer, I will take a look at this later on after my holiday's. I know the PR has been closed, but you must know I've maintained the PR for 2 years before a review came.

[martinrevert]

Thank you for the clarification @geoffreylagaisse ! If you need something, just let us know, I'll be glad to help.

@hellcry37 I think the integration has enough love from the author and users. Without the author, there's no integration, so we need to pay respect to him, his time and effort. So in terms of strict love, I think we are all ok. In terms of open source develpment cicle of life, well, things went too slow on the modernisation of the integration, then the review of the PR from the core team was too slow, and is understandable if misscommunication occurs after all that. Geoffrey surely has a life outside this, and core devs have a business to run over their open source project. But I have to be clear: My question to the maintainer was strictly administrative, we need to respect his time and will, even if he want to pull the plug off at some time. I don't want to start a riot against the maintainer followed by an endless list of user complaints after my request. I just needed to know if he pulled the plug because I was considering to fork or carry this to HACS, were it can be free from core team slow responses.

[ReenigneArcher]

In my opinion, HACS is the way to go. There's 1400 open issues and 440 PRs. Core team is too overwhelmed and shouldn't be worrying about these integrations.

[snp88]

@geoffreylagaisse how big effort for you is move this to HACS and let say treat HACS like BETA ;)?

[geoffreylagaisse]

I'll take a look at it! The heavy work has already been done I think (the configflow and making it async). I will probably have to fix a few deprecations, but nothing big. I will take a look at it first thing when I come back from holidays (beginning of September)

[petervk]

I'm also experiencing this issue. Running Home Assistant 2020.10 currently but typically update as soon as new releases are available.

[Pro-Control]

Home Assistant 2022.12.8
Supervisor 2022.11.2
Operating System 9.4
Frontend 20221213.1 - latest

1:31:13 pm – (ERROR) qbittorrent - message first occurred at 1:01:43 pm and shows up 180 times

[bogorad]

Still happens in 2023.1

Maybe there's a way to reload this integration without restarting HA?

[martinrevert]

@hellcry37 Well, it is not "just history", some users like me use the downloading or seeding states to take certain automatic actions, as move files or send notifications on downloaded contents. The ramifications of this addon showing states as "unavailable" are wide depending on the use of the information the addon gives. But yes, it is a shame that this addon is considered an "official integration" with this total lack of maintenance situation.

[ReenigneArcher]

But yes, it is a shame that this addon is considered an "official integration" with this total lack of maintenance situation.

You could say this about many integrations.

3+ years for this one... #28473

I think most integrations should be moved to HACS (as I already mentioned, ha #48158 (comment))

[gfay63]

Been trying all kinds of things to work around this issue, but nothing quite works.

Appreciate the integration, but this makes it frustrating to keep in and have to keep restarting HA when it goes unavailable even briefly.

[DcR-NL]

Take a look at this automated workaround: #81878 (comment)

[si458]

new version 2023.5 shows qbittorrent is now setupable in the UI so this issue might be fixed now
https://www.home-assistant.io/blog/2023/05/03/release-20235/

[diegomontanaduarte]

new version 2023.5 shows qbittorrent is now setupable in the UI so this issue might be fixed now https://www.home-assistant.io/blog/2023/05/03/release-20235/

Still the same issue!

[Colorado4Wheeler]

I had high hopes on this since it took so long it integrate that it might actually be working, but it is not, the same error as always. In one day I had 9,000 errors in my log. I'm giving up forever at this point, I don't think it'll ever work properly.

[gfay63]

Hey all, actually this workaround, only possible due to the new version of HA 2023.5, works perfectly! It restarts the gbittorrent integration when it detects that it needs to. Make sure and follow all the "Requirements" steps first before adding the automation.

[issue-triage-workflows]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.