Add group notification rate limits #36237

gjbadros · 2020-05-28T22:22:04Z

This enables per minute/hour/day rate limits for a notification group, and also makes it easy to enable/disable that notification group using an optional switch.

Breaking change

Proposed change

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

Example entry for `configuration.yaml`:

# Example configuration.yaml
notify:
  - name: greg_cameras
    platform: group
    services:
      - service: html5
    switch: switch.camera_notifs_enabled
    max_per_minute: 1
    max_per_hour: 12
    max_per_day: 50

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:
Forthcoming after early feedback.

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

…h to enable/disable those notifications.

probot-home-assistant · 2020-05-28T22:22:40Z

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

MartinHjelmare · 2020-05-29T10:40:49Z

homeassistant/components/group/notify.py


 PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend(
    {
        vol.Required(CONF_SERVICES): vol.All(
            cv.ensure_list,
            [{vol.Required(ATTR_SERVICE): cv.slug, vol.Optional(ATTR_DATA): dict}],
-        )
+        ),
+        vol.Optional(CONF_SWITCH): cv.entity_id,


Remove this option. This can be handled via an automation or similar.

Thanks for the quick review & feedback, Martin!

The forums seem to have lots of suggestions about possibilities, but no one best way to do this. Moreover, I can't think of a way that adds the abstraction that I'm aiming for here, which is a notification channel that I can turn on and off independently. The alternatives I'm aware of are modifying every action to do this conditionally, and that's a very global change for such a simple intent.

What's the downside of the switch? It's a clean abstraction that meshes with rate limiting (it's a temporary rate limiting to 0; one could imagine programmable/dynamicall-changeable rate limits, but that seemed like overkill compared to a simple switch). And it's literally 4 lines of code with virtually zero runtime cost.

I hope you'll reconsider?

Why should we have a switch for this condition? The condition could be anything that has a binary state. I don't think this is the correct abstraction level.

I renamed the config setting to 'enable_entity_id' to make clear that this works with any entity_id that supports is_on() (which just happens to be declared in switch.py). Is that what you were looking for?

And please let me know if there's a more refined vol check to statically enforce the guarantee that is_on() will work.. I think all entities support that since the check is just whether the state is STATE_ON.

I don't think we should add this option at all here. I think we should think more about what the best way is to accomplish the use case of this PR.

Maybe we should create some kind of general throttled action with a target action and options for the rate limit of the throttle?

I suggest making an architecture issue.

MartinHjelmare · 2020-05-29T10:44:57Z

homeassistant/components/group/notify.py

+            self.calls_minute = deque()
+            self.calls_hour = deque()
+            self.calls_day = deque()
+            self.lock = threading.Lock()


We can't use a threading lock in async context. Only asyncio locks are allowed.

Ah, good catch... will fix to use asyncio.lock. Thx!

…-- thanks Martin

gjbadros · 2020-05-29T17:48:32Z

Sure... What's the right configuration word for that and the right voluptuous check? I just don't know...

…

On Fri, May 29, 2020, 10:32 AM Martin Hjelmare ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In homeassistant/components/group/notify.py <#36237 (comment)>: > PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend( { vol.Required(CONF_SERVICES): vol.All( cv.ensure_list, [{vol.Required(ATTR_SERVICE): cv.slug, vol.Optional(ATTR_DATA): dict}], - ) + ), + vol.Optional(CONF_SWITCH): cv.entity_id, Why should we have a switch for this condition? The condition could be anything that has a binary state. I don't think this is the correct abstraction level. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALOHTKW6DC3ZOJT7HC5ZSLRT7WSBANCNFSM4NNP5EXA> .

…tems in the list (in case there's only 1 item in a list for a rate limit of 1.

…ng that supports is_on() can be used

balloob · 2020-05-29T21:29:08Z

We should not merge this PR.

Rate limiting and conditional calling things should be implemented as generic wrappers of any service. They should not be hacked into existing services because we would end up with having to add this to every service !

Conditional calling is already available by wrapping a service in a script with a condition. Rate calling should be implemented likewise.

gjbadros · 2020-05-29T22:13:43Z

What's the right place to discuss this stuff in advance of submitting a PR?

Nobody seems to comment on most feature requests -- e.g., https://community.home-assistant.io/t/scripts-need-a-finally-sequence-block/183424 where I still have no guidance on whether a PR to implement that would be accepted.

I like your idea of doing this inside a script, and think that's reasonable too/instead. I do think that notifications are very explicitly something that people expect to have rate-limiting controls on.

N.B., that notify.group could've been implemented using a script to notify multiple notification channels, but it wasn't done like that because it's a nice abstraction, just like I think this was.

balloob · 2020-05-29T22:41:53Z

Best place to discuss this is in the architecture repository, as it requires a new addition to the script syntax. See also a similar discussion about extending synax

Added support for optional group notification rate limits and a switc…

eef8060

…h to enable/disable those notifications.

homeassistant added the cla-signed label May 28, 2020

probot-home-assistant bot added core integration: group integration: notify new-feature labels May 28, 2020

project-bot bot added this to Needs review in Dev May 28, 2020

Reordered imports per isort

50974b6

MartinHjelmare changed the title ~~Added support for optional group notification rate limits and more~~ Add group notification rate limits May 29, 2020

MartinHjelmare requested changes May 29, 2020

View reviewed changes

Dev automation moved this from Needs review to Review in progress May 29, 2020

Fixed order of imports, use asyncio.Lock() instead of threading.Lock …

577ca72

…-- thanks Martin

gjbadros added 5 commits May 29, 2020 11:10

Use async with for the async lock

96e50a2

Complete the conversion to async lock; this has now been tested.

e70cc16

Handle low rates better by using current time for the span, not the i…

7164038

…tems in the list (in case there's only 1 item in a list for a rate limit of 1.

Use 'enabled_entity_id' instead of 'switch' to make more clear anythi…

54e5e69

…ng that supports is_on() can be used

Renamed CONF_SWITCH in 2nd location.

2605f24

balloob closed this May 29, 2020

Dev automation moved this from Review in progress to Cancelled May 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add group notification rate limits #36237

Add group notification rate limits #36237

gjbadros commented May 28, 2020

probot-home-assistant bot commented May 28, 2020

MartinHjelmare May 29, 2020

gjbadros May 29, 2020

MartinHjelmare May 29, 2020

gjbadros May 29, 2020

MartinHjelmare May 29, 2020

MartinHjelmare May 29, 2020

gjbadros May 29, 2020

gjbadros commented May 29, 2020 via email

balloob commented May 29, 2020

gjbadros commented May 29, 2020

balloob commented May 29, 2020

Add group notification rate limits #36237

Add group notification rate limits #36237

Conversation

gjbadros commented May 28, 2020

Breaking change

Proposed change

Type of change

Example entry for configuration.yaml:

Additional information

Checklist

probot-home-assistant bot commented May 28, 2020

MartinHjelmare May 29, 2020

Choose a reason for hiding this comment

gjbadros May 29, 2020

Choose a reason for hiding this comment

MartinHjelmare May 29, 2020

Choose a reason for hiding this comment

gjbadros May 29, 2020

Choose a reason for hiding this comment

MartinHjelmare May 29, 2020

Choose a reason for hiding this comment

MartinHjelmare May 29, 2020

Choose a reason for hiding this comment

gjbadros May 29, 2020

Choose a reason for hiding this comment

gjbadros commented May 29, 2020 via email

balloob commented May 29, 2020

gjbadros commented May 29, 2020

balloob commented May 29, 2020

Example entry for `configuration.yaml`: