-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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
Add Traffic Rule switches to UniFi Network #118821
Conversation
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.
Hey there @Kane610, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
@bdowden - you need to sign the CLA for copyright issues before this can move forward |
@EliSchleifer I did. When I go to the link it says no pending request. |
You should be able to mark the PR as ready for review. It’s currently marked as draft. Also probably needs to rerun those CI jobs to clear the block.
…________________________________
From: bdowden ***@***.***>
Sent: Tuesday, June 4, 2024 6:04:25 PM
To: home-assistant/core ***@***.***>
Cc: Eli Schleifer ***@***.***>; Mention ***@***.***>
Subject: Re: [home-assistant/core] Add Traffic Rule switches to UniFi Network (PR #118821)
@EliSchleifer<https://github.com/EliSchleifer> I did. When I go to the link it says no pending request.
—
Reply to this email directly, view it on GitHub<#118821 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJVCPWXDS3MNWVVJG5G3IDZFZPZTAVCNFSM6AAAAABIY22SEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGY3DCMRSGY>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
b467351
to
1be4ee5
Compare
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.
First round of comments, I need to think about the updatecoordinator and read up on it a bit
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
@Kane610 I wasn't sure about updatecoordinator either. I saw your comment in the other PR that a simple polling mechanism to get the updated status of the traffic rule would be fine and began to implement that. I saw that there was an update coordinator that did polling based on a given time so I didn't want to reinvent the wheel. |
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.
I have rewritten test fixtures in the integration so you would need to adapt to the new testing style, should affect you very much. Two other minor things to correct.
131070d
to
46018a0
Compare
@Kane610 Do you mind helping me out? I can't figure out how to get the traffic rule config added to the entities. I've spent far longer than I care to admit looking for the magic code and I can't find it :( |
Me too - great work guys! |
Sorry, I missed this. Run only the traffic rule test and do some printing in the entity_loader should give you everything you need |
…e appended to support v2 api requests Fix traffic rule unit tests;
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.
Almost there
…ffic rule unique ID prefix
re: Update Coordinator This is an interesting situation. Currently it won't reset the polling timer because the update coordinator isn't tied specifically to the traffic rules; instead it uses its timer to call a function on the entity loader to update a group of entities (it just so happens that it's only traffic rules). I think there are benefits to resetting the timer for any entities that are updated outside of the update coordinator. As it's currently written, though, it's polling for a group of entities. To support resetting for a single item, I think there would have to be a single coordinator per entity; for only traffic rules is fine but there may be performance issues with multiples |
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.
Some minor things left to handle
Thanks! |
control_fn=async_traffic_rule_control_fn, | ||
device_info_fn=async_unifi_network_device_info_fn, | ||
is_on_fn=lambda hub, traffic_rule: traffic_rule.enabled, | ||
name_fn=lambda traffic_rule: traffic_rule.description, |
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.
As there is a name property in the test data for traffic rules, why did you go for description over name?
Breaking change
Proposed change
Add switch entities for unifi traffic rules. This is branched from ViViDboarder's PR with fixes and implementations for the suggestions in that PR. I know what it's like to have a newborn and how time slips away.
It's also my first PR for home assistant so suggestions/clarifications on some classes are welcome!
Type of change
Additional information
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: