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

Missing support for new Bluetooth (Gen4) lights #58

Closed
LiSongMWO opened this issue Oct 28, 2020 · 4 comments
Closed

Missing support for new Bluetooth (Gen4) lights #58

LiSongMWO opened this issue Oct 28, 2020 · 4 comments

Comments

@LiSongMWO
Copy link

LiSongMWO commented Oct 28, 2020

I got a new Hue light yesterday with bluetooth support (gen4) with the identifier LTA001. This caused hueplusplus to crash on enumerating the lights with:

Oct 28 11:49:37 raspberrypi photon-hue-service[24287]: terminate called after throwing an instance of 'std::runtime_error'
Oct 28 11:49:37 raspberrypi photon-hue-service[24287]:   what():  Could not determine HueLight type!

This is caused by the string "LTA001" missing from the check here:

else if (type == "LLM010" || type == "LLM011" || type == "LLM012" || type == "LTW001" || type == "LTW004"

Presumably there are other new lights that are also missing that I don't know of.

In general I believe that the approach of enumerating all product IDs here to determine their capabilities is going to cause this class on sins of omission to continue appearing as new products are created by Philips. Is there no way to query the lights to get their capabilities from the API so that a hard coded list like this isn't needed?

@Jojo-1000
Copy link
Collaborator

There is, and it is implemented on the development branch along with a bunch of other changes.

You can look at #57 for more detail, TL;DR:

  • development branch has a lot of breaking changes, so release is planned once feature-complete
  • capabilities only works for newer bridges
  • I replaced this exception with a warning on the development branch, because the light is still usable even on older bridges
  • the color conversion approach from RGB to XY and brightness (recommended by Hue) does not look consistent

I would be especially interested in feedback on the color conversion. Maybe it needs to be rolled back to only affect XY and leave brightness alone.

@enwi
Copy link
Owner

enwi commented Oct 30, 2020

@EmilyBjoerk Can you confirm that the development branch is working for you?

@LiSongMWO
Copy link
Author

@enwi I'm using my fork that I've locked at an older commit with some of my fixes on. I don't currently have the time to rework my code to work with the breaking changes in the development branch. So unfortunately I haven't tested and will unlikely have the time to test. (I've applied a fix to my local fork for the light that I needed already).

@enwi
Copy link
Owner

enwi commented Nov 1, 2020

Okay then I will close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants