Dynamically discover mac address of bridge + HACS improvements

upsert / lutron-caseta-pro

Custom Home Assistant Component for Lutron Caseta Smart Bridge PRO / RA2 Select

Apache License 2.0

184 stars 37 forks source link

Dynamically discover mac address of bridge + HACS improvements #55

Closed rsnodgrass closed 2 years ago

rsnodgrass commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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.

rsnodgrass commented 4 years ago

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

upsert commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 (mailto:notifications@github.com)> 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 (https://github.com/upsert/lutron-caseta-pro/pull/55#issuecomment-633985640), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAQY4XBW3PIBI3W5M5FEBHTRTOWWFANCNFSM4NFLVPKA).

upsert commented 2 years ago

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.