Add configuration for extra Unifi device_tracker attributes

[cgarwood]

Description:

The Unifi device tracker adds a lot of extra attributes to devices, such as rx/tx rates, rx/tx bytes, signal strength, etc. which cause a lot of extra state changed events to be fired and logged in the database. This update adds a configuration option, extra_attributes, defaulting to False (disabled). This is technically a breaking change since it defaults to false.

This is my first time working with tests, so I'm not sure I updated the test_unify.py file correctly.

Related issue (if applicable): fixes #14745

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#5921

Example entry for configuration.yaml (if applicable):

device_tracker:
  - platform: unifi
    host: 192.168.1.201
    verify_ssl: false
    username: !secret unifi_username
    password: !secret unifi_password
    extra_attributes: true
    new_device_defaults:
      track_new_devices: false

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

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

• Documentation added/updated in home-assistant.github.io

[houndci-bot]

continuation line under-indented for visual indent

[awarecan]

I prefer not to introduce breaking change by make extra_attributes default is True.

[awarecan]

We prefer guard clause

if not self._extra_attributes:
    return {}

bla bla

[cgarwood]

I prefer not to introduce breaking change by make extra_attributes default is True.

I debated on that for a bit myself. My thought is that 90% of people aren't going to use the extra attributes that were introduced, and for those people it's writing a ton of data to the database for no gain, and since a lot of people are on Pi's with SD cards, the less writes the better. Likewise, it would only be a breaking change for people who have written automations/templates utilizing those attributes.

I can definitely change the default to true though, if that's what's preferred.

[awarecan]

Alright, let's see what others think.

[jeradM]

I think a breaking change is ok here. This should have been opt-in from the beginning

[frenck]

Missing documentation PR in the OP.

[cgarwood]

Docs added, should be good to go now.

[frenck]

Thanks, @cgarwood! Removing the label.

[dgomes]

I also think that a breaking change is advisable here

[jjlawren]

As suggested in the linked issue, I agree with a breaking change to exclude this extra data. There are likely others that simply haven’t noticed the negative storage effects yet.

[awarecan]

LGTM

[awarecan]

default=False is better then default=DEFAULT_EXTRA_ATTRIBUTES

[dgomes]

It would not be consistent we the remaining DEFAUT_*

[smkelly]

Have you considered also making this accept a list of attributes you actually do want from Unifi? Then you can collect what you care about and discard the rest. This is similar to telling the darksky sensor what weather data you want.

[cgarwood]

@smkelly that does seem like a better route to go. I modified the code on my dev box to use monitored_conditions list instead of an extra_attributes boolean config and its working OK on my dev box.

Before I commit it and update this PR, what are your thoughts @awarecan ?

[cgarwood]

Created a new PR to use a monitored_conditions list instead. #15888