Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Kuler Sky Bluetooth floor lamp integration #42372

Merged
merged 7 commits into from
Dec 2, 2020

Conversation

emlove
Copy link
Contributor

@emlove emlove commented Oct 25, 2020

Proposed change

This PR introduces a new component for Brightech Kuler Sky bluetooth floor lamps. https://smile.amazon.com/Brightech-Kuler-Sky-Torchiere-Adjustable/dp/B01LDT39AE

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)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

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
  • The code has been formatted using Black (black --fast homeassistant tests)
  • Tests have been added to verify that the new code works.

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

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.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

  • No score or internal
  • 🥈 Silver
  • 🥇 Gold
  • 🏆 Platinum

To help with the load of incoming pull requests:

_LOGGER.error("Exception scanning for Kuler Sky devices", exc_info=exc)
return self.async_abort(reason="scan_error")

options = [
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why allow the user to pick? We could replace this config flow with https://developers.home-assistant.io/docs/config_entries_config_flow_handler#discoverable-integrations-that-require-no-authentication and then have the light platform set them all up. The user can disable the entities of the lights they don't want.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I could have sworn I commented this somewhere, but I don't see it. 🤦‍♀️ The problem with these devices is they don't expose any identifying information, at least nothing available to the underlying pygatt library. So the best that pykulersky can do is discover all nearby bluetooth devices. (I need to update that library discover method name to make it more clear) So the options we've got are either have the user pick the correct device, or attempt to connect to each discovered bluetooth device, which could potentially leave the user waiting at the spinner for a while if there are a lot of other bluetooth devices in the vicinity. I'm OK with either option, but those are the tradeoffs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review!

I pushed up some comments, and renamed the upstream method so that the current behavior is at least more clear when reading the code. Still happy to switch to plan B if you'd prefer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The discovery config flow only requires a single light to be discovered to set up the config flow. (Just wants to make sure a device can be found).

After that it finishes the flow and lights will be added to Home Assistant as discovery picks up more.

Copy link
Member

@balloob balloob Nov 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that having the user pick a bluetooth address is putting burden on the user. Having a user wait while we figure out if they have any device is a lot better experience compared to having the user set up each individual device and having to figure out their addresses too (noticed we have name too).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even discovering the first light could be really slow though, since we'll have to attempt a connection with every nearby bluetooth device before we know if it's a valid device. I'll switch it over though. Sounds like simple but slow is the preferred solution.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can change the discovery flow to just check if Bluetooth works ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I like that idea! Should be a quick test to ensure the bluetooth stack is working, and the devices will be available once they're discovered. 👍

if brightness == 0 and white_value == 0 and not kwargs:
# If the light would be off, and no additional parameters were
# passed, just turn the light on full brightness.
brightness = 255
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to pass nothing, and it turns on with the last values before it was turned off?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately these lights don't have that capability.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Laaaaaaaaaaame

@@ -0,0 +1,20 @@
{
"title": "Kuler Sky",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for this, HA defaults to the manifest title. Since it's a brandname, we don't want it translated.

Copy link
Member

@balloob balloob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Few minor comments!

@emlove emlove force-pushed the kulersky branch 3 times, most recently from 6c15a74 to 6dab4c5 Compare November 13, 2020 20:16
@emlove emlove force-pushed the kulersky branch 2 times, most recently from fc06d2e to 2d44a3f Compare November 13, 2020 20:21
@emlove
Copy link
Contributor Author

emlove commented Nov 27, 2020

OK, updated to the new discovery strategy! It's looking a lot cleaner now.

Copy link
Member

@balloob balloob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay. My notifications are flooded.

@balloob balloob merged commit 7c83092 into home-assistant:dev Dec 2, 2020
@balloob balloob added this to the 1.0.0 milestone Dec 2, 2020
@balloob
Copy link
Member

balloob commented Dec 2, 2020

Tagged it so it will be in the next release :)

@emlove emlove deleted the kulersky branch December 3, 2020 02:23
@emlove
Copy link
Contributor Author

emlove commented Dec 3, 2020

No worries. Thanks for your help!

Copy link
Member

@MartinHjelmare MartinHjelmare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Some small comments.



config_entry_flow.register_discovery_flow(
DOMAIN, "Kuler Sky", _async_has_devices, config_entries.CONN_CLASS_UNKNOWN
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should update the connection class to be one of the standard classes except unknown, eg CONN_CLASS_LOCAL_POLL.

CONN_CLASS_CLOUD_PUSH = "cloud_push"
CONN_CLASS_CLOUD_POLL = "cloud_poll"
CONN_CLASS_LOCAL_PUSH = "local_push"
CONN_CLASS_LOCAL_POLL = "local_poll"
CONN_CLASS_ASSUMED = "assumed"

# device. If the vendor's app is connected to the light when
# home assistant tries to connect, this connection will fail.
await hass.async_add_executor_job(light.connect)
await hass.async_add_executor_job(light.get_color)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could optimize this a bit by wrapping both calls inside of one function that we schedule on the executor.

async_add_entities([KulerskyLight(light)], update_before_add=True)

# Start initial discovery
hass.async_add_job(discover)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use hass.async_create_task instead. hass.async_add_job is legacy for general use.

@emlove emlove mentioned this pull request Dec 3, 2020
21 tasks
@emlove
Copy link
Contributor Author

emlove commented Dec 3, 2020

Thanks for the follow-up @MartinHjelmare ! I've pushed up a cleanup PR here #43901

frenck pushed a commit that referenced this pull request Dec 5, 2020
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants