-
-
Notifications
You must be signed in to change notification settings - Fork 37.4k
Add Synology DSM Security API #35305
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,6 +20,7 @@ | |
| BASE_NAME, | ||
| CONF_VOLUMES, | ||
| DOMAIN, | ||
| SECURITY_SENSORS, | ||
| STORAGE_DISK_SENSORS, | ||
| STORAGE_VOL_SENSORS, | ||
| SYNO_API, | ||
|
|
@@ -42,6 +43,12 @@ async def async_setup_entry( | |
| for sensor_type in UTILISATION_SENSORS | ||
| ] | ||
|
|
||
| if api.security: | ||
| sensors += [ | ||
| SynoNasSecuritySensor(api, sensor_type, SECURITY_SENSORS[sensor_type]) | ||
| for sensor_type in SECURITY_SENSORS | ||
| ] | ||
|
|
||
| # Handle all volumes | ||
| if api.storage.volumes_ids: | ||
| for volume in entry.data.get(CONF_VOLUMES, api.storage.volumes_ids): | ||
|
|
@@ -135,7 +142,7 @@ def should_poll(self) -> bool: | |
|
|
||
| async def async_update(self): | ||
| """Only used by the generic entity update service.""" | ||
| await self._api.update() | ||
| await self._api.async_update() | ||
|
|
||
| async def async_added_to_hass(self): | ||
| """Register state update callback.""" | ||
|
|
@@ -208,3 +215,33 @@ def device_info(self) -> Dict[str, any]: | |
| "sw_version": self._api.information.version_string, | ||
| "via_device": (DOMAIN, self._api.information.serial), | ||
| } | ||
|
|
||
|
|
||
| class SynoNasSecuritySensor(SynoNasSensor): | ||
| """Representation a Synology Security sensor.""" | ||
|
|
||
| @property | ||
| def state(self): | ||
| """Return the state.""" | ||
| return getattr(self._api.security, self.sensor_type) | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 ?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you are spot on and it should be a binary sensor.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. binary sensor yes. There is even a https://developers.home-assistant.io/docs/entity_binary_sensor#available-device-classes Note that off means safe. |
||
|
|
||
| async def async_remove(self): | ||
|
Quentame marked this conversation as resolved.
|
||
| """Clean up when removing entity. | ||
|
|
||
| Remove entity if no entry in entity registry exist. | ||
| Remove entity registry entry if no entry in device registry exist. | ||
| Remove entity registry entry if there are more than one entity linked to the device registry entry. | ||
| """ | ||
| entity_registry = await self.hass.helpers.entity_registry.async_get_registry() | ||
| entity_entry = entity_registry.async_get(self.entity_id) | ||
| if not entity_entry: | ||
| await super().async_remove() | ||
| return | ||
|
|
||
| device_registry = await self.hass.helpers.device_registry.async_get_registry() | ||
| device_entry = device_registry.async_get(entity_entry.device_id) | ||
| if not device_entry: | ||
| entity_registry.async_remove(self.entity_id) | ||
| return | ||
|
|
||
| entity_registry.async_remove(self.entity_id) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with Nick. This should not be an option but just disabled by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you are ok to make a request to fetch security data even if we don't use it ?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Searching to not make that with
entity_registry_enabled_defaultThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see
https://github.com/ProtoThis/python-synology/blob/674dfb3c943e464680c33c8bc4975139d8c72f5c/synology_dsm/synology_dsm.py#L258-L314
To think what I can do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bdraco Yes, but in the case we have one
DataUpdateCoordinatorper API:When requesting a
storagefetch (and with asecuritycoordinator somewhere) the libupdatewill fetch storage + securityAfter, the security
DataUpdateCoordinatorwill also update with fetch storage + security.So it doubles requests !
OR,
Every
DataUpdateCoordinatorshould have its own instance ofSynoApiorSynologyDSM, it will do even more requests and will login to the NAS for everyDataUpdateCoordinator, I beat it will have an error at login (logged multiple times)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You would need to some refactoring remove the the
updateand only have the coordinator instances for each endpoint share the singleSynologyDSMso you aren't logging in multiple times.There is a good example on how to accomplish this in
nws/__init__.py:async_setup_entryUh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes totally, setting the sensor to off will make the API continue to fetch on it.
Not totally, one option per API, not per sensor.
Maybe, at
SynoApi.async_updateI can check all entities of this config, and if all entities of a specific API are disabled: something like thisself.dsm._security = None.@bdraco Do you know how to get all entities of one config ?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like this:
I suppose
EDIT:
async_entries_for_config_entryUh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.pyhas an example