Direct HSV/RGB API Call?

[dsully]

Hi - I’m working on a HomeBridge plugin for HomeKit.

Right now there isn’t an easy way to directly set the HSV via the WebSocket API.

It looks like I’d need to create a pattern, and then set variables within that pattern. Not a good UX for an out-of-the-box experience.

Would it be possible to add an API to directly set the entire strip to either HSV or RGB at a given brightness?

Thanks!

[zranger1]

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)

Home Assistant Custom Integration

For those interested in integrating your pixelblaze into Home Assistant, I’ve setup a github repository for a custom integration. vutang50/homeassistant-pixelblaze From Home Assistant - you can control the brightness, start the sequencer, set the pattern from the installed pattern list, and if the pattern supports it, a single color picker. You can extend this further by setting up automation, such as switching to a sound pattern when playing music with a media_player [Custom Light Entity…

Hubitat Elevation (Home automation) integration

I’ve just updated the Pixelblaze driver for Hubitat to version 2.0! It’s available from my repository (at the top of the thread) or via the Hubitat Package Manager. This version features many performance and reliability improvements, plus: Support for color and speed controls in patterns. - if a pattern includes a color slider, the driver will detect it and will allow you to the Hub’s normal color bulb controls. Similarly if the pattern includes a “Speed” slider, the driver will allow you…

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.

[dsully]

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.

Thanks

[wizard]

Hi @dsully,
How would you imagine it to work? Does the simplified controls set every pixel to the same color, e.g. for architectural lighting?

The general method of getting PB to do things is with a pattern, even a simple single color pattern like “Single Color Picker - wide or spot”, attaching here:

Single Color Picker - wide or spot (5).epe (2.9 KB)

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.

[dsully]

Yes, exactly like architectural lighting.

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.

[dsully]

Ok, got distracted with other things.

Here’s the repository: https://github.com/dsully/homebridge-pixelblaze

With the plugin also packaged on NPM.

[Nick_W]

Interesting, I’m doing a similar thing. Writing an MQTT interface to Pixelblaze using async web socket interface.

I just wrote a simple pattern that exposes r,g,b (could be h,s,v), and writes the values to the whole strip.

Brightness is controlled by sending {“brightness”: value} where value is 0-1.

Pretty simple.

Of course built in websocket rgb control would avoid the need for a pattern at all.