Add Uplink info to UniFi Device tracker attributes

[ViViDboarder]

Proposed change

Adds attributes to UniFi Device Tracker to provide upstream information. Intended use case here is for tracking when upstream failover happens.

I'm also open to this being a dedicated sensor and limiting it to routers rather than any "UniFi device", but this was the simplest change so I figured I'd start here because similar data is already read as attributes for "UniFi clients".

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)
• Deprecation (breaking change to happen in the future)
• 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
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format 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.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @Kane610, mind taking a look at this pull request as it has been labeled with an integration (unifi) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of unifi can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign unifi Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[Kane610]

Awesome! In almost all cases it's now preferred to create separate sensors, I will at one point in time create sensors from the current attributes as well.

[ViViDboarder]

Done! This will do the job for what I'm trying to accomplish, but I just got to thinking in relation to the WAN stats PR... would it be useful to think in terms of WAN sensors?

This PR is the uplink for any device, so it will be the MAC of the router for any AP, so it has possible usage outside of my usecase, but a WAN category of sensors would include things like availability percentage, is up, is uplink (currently used as uplink), IP address, and tx data (bytes, dropped, etc.).

I don't know if that would make sense to think of "WANs" as a virtual "Device" or just add the sensors to the router devicethat has wan subobjects.

With this PR, my workflow would look something like "Create automation that looks for the uplink MAC on my router changing to the MAC of my backup internet modem". The extended WAN approach would be something like, "Create automation that looks for "WAN2 Is Uplink is True" to determine if I'm in a failover state.

[ViViDboarder]

Oh, furthermore, it looks like the geo_info object is keyed by WAN to provide more info like ASN, and ISP Name and ISP Org. Those would be useful as well to go as attributes associated with WAN IP or something.

[home-assistant]

There is a merge conflict.

[Kane610]

I think this is Ok! I will wait a week or so to merge as the new release is tomorrow.

You also need to make Ruff pass

[Kane610]

After rebase and this final comment I think that this is ready to merge

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Stale

[Kane610]

Awesome! Just noticed the test string is wrong, can you fix that. Ready to merge after that

[Kane610]

Thanks @ViViDboarder