Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the Qnap sensor more resilient if server is not reachable #16445

Merged
merged 5 commits into from
Sep 10, 2018

Conversation

mrosseel
Copy link
Contributor

@mrosseel mrosseel commented Sep 5, 2018

Description:

My Qnap NAS server is booted on a schedule, so it's not always on when HA restarts.
Current behaviour is that if the NAS is not online, a persistent notification is posted and there's an error in the log.

Goal: silence this error if the NAS is not reachable, and let HA retry the connection till the NAS is on.

What I did:

  • added a configuration boolean 'ALLOW_UNREACHABLE'
  • checked that if the NAS is not found and this boolean is True, the notification is not triggered.
  • raise PlatformNotReady so that HA will retry

possible issues:

  • added ALLOW_UNREACHABLE to const.py, I realise this might not be wanted but there are many other components having this config option but declaring it in their own .py file. If this PR is accepted, some cleanup is possible in these files.
  • if the NAS goes offline again, the old values are kept so we risk looking at stale values. This is also the case in the current implementation.
  • I've held of on the documentation as this is my first PR, first want to see if the direction is ok etc.
  • There was no test for this file, and I haven't added any.

Example entry for configuration.yaml (if applicable):

sensor:
  - platform: qnap
    host: 192.168.0.10
    ssl: false
    username: user
    password: mypassword
    allow_unreachable: True
    monitored_conditions:
      - status
      - cpu_usage

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

If the code does not interact with devices:

  • Tests have been added to verify that the new code works.

@mrosseel mrosseel requested a review from a team as a code owner September 5, 2018 21:20
@homeassistant
Copy link
Contributor

Hi @mrosseel,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@@ -99,6 +101,7 @@
vol.Optional(CONF_NICS): cv.ensure_list,
vol.Optional(CONF_DRIVES): cv.ensure_list,
vol.Optional(CONF_VOLUMES): cv.ensure_list,
vol.Optional(CONF_ALLOW_UNREACHABLE, default=False): cv.boolean,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you make that as option?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi, the reasoning is that if this setting is False (the default), this sensor keeps its old behaviour. This is for people who have their NAS on 24/7 and want to see the notification. Setting it to True hides the notification and uses the HA PlatformNotReady mechanism.

BUT: maybe this option should dissapear and the PlatformNotReady should become the default, ditching the notification, that's another option and I'm open to opinions on this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be only PlatformNotReady and the should be covered/handled by available(). Adding an option to configure the behavior of the notification looks wired .

Copy link
Contributor Author

@mrosseel mrosseel Sep 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, ok If I understand correctly you would just drop the config option and the notification, and use PlatformNotReady as the only behaviour. Sounds good, I'll remove the config + notification. Anything else that needs to be changed? Not familiar with "available()".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Available property is simple: return False if the the device is not reachable (maybe the state fetch going wrong on update) and True if they is back.

@frenck
Copy link
Member

frenck commented Sep 9, 2018

Could not find a matching documentation PR. Added docs-missing label.

@mrosseel
Copy link
Contributor Author

mrosseel commented Sep 10, 2018

  • removed the configuration option
  • removed the notification (old behaviour when qnap nas was not available)
  • used PlatformNotReady exlusively. Returning False did not trigger the retry behaviour which happens in the case of PNR. If there's some other mechanism which would be even better, please point me to an example.

Note: The docs_missing label can probably be removed because from a user's perspective, nothing described in the docs has changed.

@frenck
Copy link
Member

frenck commented Sep 10, 2018

@mrosseel Correct! Since the parameter has been removed.

Copy link
Member

@fabaff fabaff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 🐦

@fabaff fabaff merged commit f858938 into home-assistant:dev Sep 10, 2018
@ghost ghost removed the in progress label Sep 10, 2018
@mrosseel mrosseel deleted the qnap branch September 10, 2018 14:29
@balloob balloob mentioned this pull request Sep 28, 2018
@home-assistant home-assistant locked and limited conversation to collaborators Dec 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants