Hello and welcome!
Before you get too far down this road, you might want a look at the other home automation integrations that have been done: (disclosure: I’m the author of the Hubitat Elevation integration)
Highly programmable devices like the Pixelblaze don’t fit very well into the least-common-denominator device models used by home automation systems. The approach that has worked well lately is to build as much intelligence as possible into the integration code, and let it make real-time decisions about what device features to present to the home automation interface.
For example both the Hubitat and Home Assistant integrations control on/off state and brightness, and allow changing patterns via some sort of “effect” capability supported by the home automation system. In addition, both integrations
can evaluate a pattern’s list of UI controls, see if there are any color picker controls, and then allow the home automation system to use them if they exist. So, if a pattern has color controls, the home automation user can control them. If not, the controls are disabled.
The Hubitat integration offers even tighter coupling with certain patterns – you can run a special “multisegment” pattern that lets you present the Pixelblaze to the home automation system as up to 12 independent light bulbs, each with independent colors and effects.
Keep us posted on your plugin. I’m more than happy to share code, ideas and solutions to strange problems that I encountered along the way.
Thanks - I’ve seen your Python code already (BTW, you should remove the ‘dist’ and ‘pixelblaze_client.egg-info’ directories from your Git repo, they’re not meant to be committed) and the Hubitat driver.
I aware of the limitations of HomeKit / Homebridge and also what the Pixelblaze provides, which is why after a lot of research I still chose Pixelblaze for my needs.
I’m planning on exposing both basic RGB & brightness controls, along with a selector for picking different patterns right now.
However, having an easier way to set HSV/RGB would go a long ways towards that.
I wonder if adding some kind of simple webhook/message that would trigger a pattern to load and optionally feed data to its controls would do the trick. That could be used to wire up a “single color” pattern, or something more advanced.
Future versions of PB could ship with a simple color pattern and a pre-configured webhook that would give you a ready-to-run out of box experience for a color picker, while providing the tools to do way more.
I’m all for making it easier to integrate, and I’d like to hear about any findings you have working with homebridge.
What you propose would definitely work. As I have it today, hue & saturation data would come from HomeKit characteristics, and passed along to the websocket handle.
In terms of the single color pattern - if you would prefer to keep all the logic in patterns as opposed to adding a whole-strip/LED specific API I can work work that, but providing an out-of-the-box non-pattern based approach would also be nice.
I’ll throw what I have up on GitHub in a bit - thanks for Firestorm, it made this go a lot faster.