Dynamically discover mac address of bridge + HACS improvements

[rsnodgrass]

• dynamically discover mac address of bridge (config does not need to be specified for entity registry to work)
• rename README.md to be HACS compatible as default README
• adds hacs.json for improved HACS support (default readme)

[sreknob]

according to #56 & #57 there may be issues with HA <110
maybe also specify a minimum version in hacs.json to prevent people breaking their current installations if they don't want to upgrade yet....

{
  "name": "Lutron Caseta Smart Bridge PRO / RA2 Select",
  "domains": [ "cover", "fan", "light", "scene", "sensor", "switch" ],
  "homeassistant": "0.110",
  "render_readme": true
}

[rsnodgrass]

according to #56 & #57 there may be issues with HA <110
maybe also specify a minimum version in hacs.json to prevent people breaking their current installations if they don't want to upgrade yet....

Good point about minimum version for the updated version. I have updated this to include that limitation (now that we have a hacs.json file).

[rsnodgrass]

@upsert can you look at this change, it now restricts updates to 0.110 (with thew new hacs.json file) and automatically discovers the MAC address of the bridge.

[upsert]

The info.md was provided for rendering in HACS. It should not need the readme rendered as it is very long.

[rsnodgrass]

@upsert Aha, thanks for catching that. I have removed render_readme and did an editing pass on the info.md file.

[upsert]

I've done some testing and I'm seeing that get_mac_address returns 00:00:00:00:00:00 the first time you run it when the ARP cache is empty. It causes the devices to be setup using 00:00:00:00:00:00 as the unique ID and then if you restart Home Assistant, it successfully gets the MAC from the warm cache and sets them up under their proper unique ID. It results in duplicates of all the devices.

It is not clear if this is an issue with the getmac library or there is something else that needs to be done to get it to work. I tried adding network_request=True and it did not seem to make a difference.

Tested on a virtual machine running Ubuntu 18.04.04 LTS.

[upsert]

I've integrated your changes to info.md, README.md and the HACS file. The JSON should help head off issues being raised due to the recent breaking changes and the requirement for 0.110.

[rsnodgrass]

Great. I hope to have time to look at 00:00:00:00:00 MAC issue in next few days. Three thoughts: * Persist previous IP to MAC mappings across restarts and use when look up fails * Delay sensor creation and periodically recheck MAC every second until it resolves (but I don’t like any delay in availability of light control on startup) * or...just back out change and leave manual config only

…

On May 26, 2020 at 5:11 AM, <upsert ***@***.***)> wrote: I've integrated your changes to info.md, README.md and the HACS file. The JSON should help head off issues being raised due to the recent breaking changes and the requirement for 0.110. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#55 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAQY4XBW3PIBI3W5M5FEBHTRTOWWFANCNFSM4NFLVPKA).

[bdraco]

This does I/O and can also throw an exception. It should be wrapped in await hass.async_add_executor_job. ... probably will need partial as well due to the keyword arg.

[upsert]

At this point, this custom component is in maintenance mode and will not be adding new features or dependencies. See the built-in integration for Lutron Caséta for more features including auto-discovery.