Support RGBW Values as an Alternative to Hue and Saturation

[juangamnik]

My light bulb expects brightness and either red, green, blue, white or temp values (if in color or white mode respectively). You can add a gain value, too, but I'm not aware what it does...

So it would be great, if one could set the RGB-Values via http instead of hue and saturation. If Homebridge expects it this way, of course this would then needed to be converted. I can try to add this myself, but at a first glance at your code I could not see how to implement this.

Thank you very much in advance.

[Supereg]

Never heard of gain in the context of colored lightning.

If you rely on RGB you might be better of with a dedicated RGB lightning plugin:

• https://github.com/BCornelsen/homebridge-wled
• https://github.com/QuickSander/homebridge-http-rgb-push/

[juangamnik]

I tested some of the http-x plugins and yours seem to work exceptionally well, so if possible I would stick to it. I come from programming too, so adding a parameter rgbw to the plugin configuration and mapping it internally to hue and saturation via JavaScript libs (I think you use it already the other way around at some point), should be relatively easy, isn‘t it? If you point me at the right lines in your code I‘ll try it myself.

What do you think?

[juangamnik]

Further on, these plugins just offer to put a color hex-value as a %s in the url instead of offering either three urls each for red, green, and blue values (either percent or 0..255) or the possibility to do something like this http://<device-url>?red=%s&blue=%s&green=%s. This excludes many devices/apis.

[Supereg]

Hey, thanks for your interest. I would love to support your use case with the plugin. Though, this would require a major modification to the structure of the plugin. To be honest, I'm not sure if I want to invest the time doing so, assuming I would have the time to do so 🙃 I hope you understand. So, while I think this feature request is absolutely valid, I want to be realistic and say that this feature probably won't come any time soon.

I think you use it already the other way around at some point

Well kinda, I tried to use that to support the ColorTemperature characteristic alongside to Hue and Saturation. But as my comment in the code states: // this algorithm is actually completely broken. At least the last time I checked.

If you point me at the right lines in your code I‘ll try it myself.

Well, you would need to collect the write requests to the Hue and Saturation characteristics such that you can from a single request to your API endpoint. Of course converse RGB values back and forth. And then somehow integrate this with the existing configuration scheme such that complexity isn't extraordinarily increased (if you wanted to a pull request). That's the point where I say, that it may not be fitting to integrate it with this plugin, but maybe create a completely separate plugin for that. As the internal structure of both are entirely different. I could envision that code complexity would grow immensely if you would try to integrate both interfacing styles into one plugin.

Further on, these plugins just offer to put a color hex-value as a %s in the url instead of offering either three urls each for red, green, and blue values (either percent or 0..255) or the possibility to do something like this http://<device-url>?red=%s&blue=%s&green=%s. This excludes many devices/apis.

Wouldn't it be easier then to create a pull request against one of those plugins to change the encoding behavior? Assuming this is not the only show stopper.

[juangamnik]

Fair enough. I‘ll reflect on that.