* Factor out _is_dmr_device function
* Use DMR device's MAC to match existing config entries
Some DMR devices change their every time they boot, against the DMR specs.
Try to match such devices to existing config entries by using their MAC
addresses.
* Add DMR device's MAC as a device_registry connection
* Use doc-only IPs (RFC5737) for dlna_dmr tests
vicare: Rename "Power production this week" sensor
'Power' should be 'Energy' like for the other timespanns.
This one was forgotten last time this area was cleaned up.
* Use the same entity class as switches, but separately
Once all platforms are migrated I will consolidate them into one entity class
* Fix review comment
* Fix review comments
* Fix review comments
* ESPHome: Use MAC as unique ID
* Normalize incoming zeroconf/dhcp macs
* Update comment
* Test ESPHome without mac in zeroconf
* Use format_mac
* Remove unique ID index from DomainData
* Add support for battery level to Yale Access Bluetooth
* fix
* bump
* bump
* bump
* bump
* fix
* bump
* battery level is always an estimate from voltage, but than again it always is for every device
* bump
* review
* bump again to fix slow start
* other one
* Make google calendar fail louder on invalid google_calendars.yaml
* Update homeassistant/components/google/__init__.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Update homeassistant/components/google/__init__.py
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Remove duplicate object key in strings.json
* Remove async_entry_has_scopes check
This is not needed. This was copied from google calendar integration
where it was needed to reauth when the scope changed.
* Remove unused constant in application_credentials
* Move constant to the file used
* fix warning use-implicit-booleaness-not-len
* Remove not accessed parameters
* Revert "Remove async_entry_has_scopes check"
This reverts commit 63e24f84cc1c0250ee5fa57c7f624bbed12e0221.
Entries took a while to setup because of the
async_wait_init_flow_finish call in _async_setup_component
The delay was so long that users thought the integration
was broken
We had a wait in place for advertisements to arrive
during discovery in case the lock was not
yet seen. Since integration discovery is deferred
until after startup this wait it no longer needed
