Add Synology DSM Security API by Quentame · Pull Request #35305 · home-assistant/core

Quentame · 2020-05-06T22:26:12Z

Proposed change

Add security sensor via config options

Type of change

Dependency upgrade
Bugfix (non-breaking change which fixes an issue)
New integration (thank you!)
New feature (which adds functionality to an existing integration)
Breaking change (fix/feature causing existing functionality to break)
Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

The code change is tested and works locally.
Local tests pass. Your PR cannot be merged unless tests pass
There is no commented out code in this PR.
I have followed the development checklist
The code has been formatted using Black (black --fast homeassistant tests)
Tests have been added to verify that the new code works.

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

Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

No score or internal
🥈 Silver
🥇 Gold
🏆 Platinum

probot-home-assistant · 2020-05-06T22:26:20Z

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

bdraco · 2020-05-06T22:36:13Z

I'll look in detail when I have a free moment.

#35106
I'm not sure the device registry cleanup is needed after this recent change ^^

Quentame · 2020-05-06T22:36:51Z

OK, will check that tomorrow

Quentame · 2020-05-07T10:21:15Z

I'll look in detail when I have a free moment.

#35106
I'm not sure the device registry cleanup is needed after this recent change ^^

It takes several seconds to clean the device (was instant before), but it did clean automatically (I've created a "Synology NAS (security)" device for testing).

bdraco · 2020-05-07T21:15:37Z

@Quentame Did you consider the entity_registry_enabled_default route instead of the options flow?

https://developers.home-assistant.io/docs/entity_registry_disabled_by#integrations-setting-default-value-of-disabled_by-for-new-entity-registry-entries

Its fine to do it either way, but it might be easier to maintain.

https://developers.home-assistant.io/docs/entity_registry_disabled_by#integrations-offering-options-to-control-disabled_by

Quentame · 2020-05-08T12:04:49Z

I did not consider entity_registry_enabled_default because I didn't used it before.

But I after reading the doc I think it should be better for synology_dsm to use options flow because it will make HA fetch the API even if we disable entries.
Don't forget that all DSM library properties are making I/O to a different API (information, network, security, utilisation, storage ...).

I prefer using option flow to prevent fetching an API we are not using.

Concerning maintainability, I don't think this code is hard to read, but checking if all entries of a specific API is disabled to prevent fetching is gonna be harder.

(maybe I'm wrong)

Quentame · 2020-05-08T12:09:43Z

+    @property
+    def state(self):
+        """Return the state."""
+        return getattr(self._api.security, self.sensor_type)


The state here is "safe", but maybe I should create a binary sensor of it instead of a sensor.

Like "Synology security safe" : on if safe, off if not, and maybe a details of it in attrs.

(I don't know all possible values)

What do you think @balloob ?

I think you are spot on and it should be a binary sensor.

binary sensor yes. There is even a safety device class :)

https://developers.home-assistant.io/docs/entity_binary_sensor#available-device-classes

Note that off means safe.

Quentame · 2020-05-08T14:08:55Z

Next PR, see commit "Refactor Synology DSM device" : https://github.com/Quentame/home-assistant/commits/synology_dsm/platform-rework

balloob · 2020-05-08T17:09:18Z

+                vol.Optional(
+                    CONF_SECURITY,
+                    default=self.config_entry.options.get(
+                        CONF_SECURITY, DEFAULT_SECURITY
+                    ),
+                ): bool,


Agree with Nick. This should not be an option but just disabled by default.

So you are ok to make a request to fetch security data even if we don't use it ?

Searching to not make that with entity_registry_enabled_default

Ideally the update function is smart enough to know that if it has no subscribers listening for the data that is should skip requesting those data sets.

Please see

https://github.com/ProtoThis/python-synology/blob/674dfb3c943e464680c33c8bc4975139d8c72f5c/synology_dsm/synology_dsm.py#L258-L314

To think what I can do

@bdraco Yes, but in the case we have one DataUpdateCoordinator per API:

When requesting a storage fetch (and with a security coordinator somewhere) the lib update will fetch storage + security

After, the security DataUpdateCoordinator will also update with fetch storage + security.

So it doubles requests !

OR,

Every DataUpdateCoordinator should have its own instance of SynoApi or SynologyDSM, it will do even more requests and will login to the NAS for every DataUpdateCoordinator, I beat it will have an error at login (logged multiple times)

You would need to some refactoring remove the the update and only have the coordinator instances for each endpoint share the single SynologyDSM so you aren't logging in multiple times.
There is a good example on how to accomplish this in nws/__init__.py:async_setup_entry

If I turn off the security sensor self._security will have already have been set here https://github.com/ProtoThis/python-synology/blob/674dfb3c943e464680c33c8bc4975139d8c72f5c/synology_dsm/synology_dsm.py#L297 so it going to continue to poll here https://github.com/ProtoThis/python-synology/blob/674dfb3c943e464680c33c8bc4975139d8c72f5c/synology_dsm/synology_dsm.py#L264

Yes totally, setting the sensor to off will make the API continue to fetch on it.

Your original approach of the option to turn on/off the sensor does eliminate this issue. The downside is that every new sensor type would have to be added to the options flow which will make it a lot more difficult to refactor later to tie specific sensors to specific api calls to avoid the ones that are disabled.

Not totally, one option per API, not per sensor.

Maybe, at SynoApi.async_update I can check all entities of this config, and if all entities of a specific API are disabled: something like this self.dsm._security = None.

@bdraco Do you know how to get all entities of one config ?

Like this:

registry = await entity_registry.async_get_registry(hass) conditions: List[Dict[str, Any]] = [] # Get all the integrations entities for this device for entry in entity_registry.async_entries_for_device(registry, device_id):

I suppose

EDIT: async_entries_for_config_entry

Generally in this case we would want each entity to subscribe to updates and then we can look at the list of subscribers and determine which endpoints to poll. august/subscriber.py has an example

Quentame · 2020-05-12T23:44:05Z

Closing in favor of #35565

homeassistant added the cla-signed label May 6, 2020

probot-home-assistant Bot added has-tests integration: synology_dsm Synology DSM new-feature by-code-owner labels May 6, 2020

Quentame requested a review from bdraco May 6, 2020 22:33

Quentame commented May 6, 2020

View reviewed changes

Comment thread homeassistant/components/synology_dsm/sensor.py Outdated

Quentame force-pushed the synology_dsm/add_security branch from d172a53 to acec2a6 Compare May 7, 2020 10:18

Quentame force-pushed the synology_dsm/add_security branch from acec2a6 to 36d3e35 Compare May 7, 2020 16:01

bdraco reviewed May 7, 2020

View reviewed changes

Comment thread homeassistant/components/synology_dsm/sensor.py Outdated

bdraco reviewed May 7, 2020

View reviewed changes

Comment thread homeassistant/components/synology_dsm/sensor.py Outdated

Quentame added 3 commits May 7, 2020 20:48

Add Synology DSM Security API

4612218

Remove device registry cleaning because it's automatic

9160f52

Remove useless options_updated

ac56962

Quentame force-pushed the synology_dsm/add_security branch from 36d3e35 to ac56962 Compare May 7, 2020 19:00

Quentame requested a review from bdraco May 7, 2020 19:13

Quentame commented May 8, 2020

View reviewed changes

Fix manual update

4799e4b

balloob reviewed May 8, 2020

View reviewed changes

Quentame closed this May 12, 2020

Quentame deleted the synology_dsm/add_security branch May 12, 2020 23:43

lock Bot locked and limited conversation to collaborators May 20, 2020

Uh oh!

Conversation

Quentame commented May 6, 2020

Proposed change

Type of change

Additional information

Checklist

Uh oh!

probot-home-assistant Bot commented May 6, 2020

Uh oh!

Uh oh!

bdraco commented May 6, 2020

Uh oh!

Quentame commented May 6, 2020

Uh oh!

Quentame commented May 7, 2020

Uh oh!

Uh oh!

Uh oh!

bdraco commented May 7, 2020

Uh oh!

Quentame commented May 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Quentame commented May 8, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Quentame May 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Quentame May 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Quentame May 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bdraco May 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Quentame commented May 12, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Quentame commented May 8, 2020 •

edited

Loading

Quentame May 10, 2020 •

edited

Loading

Quentame May 10, 2020 •

edited

Loading

Quentame May 10, 2020 •

edited

Loading

bdraco May 10, 2020 •

edited

Loading