[RELEASE] Pixelblaze addressable LED Controller Driver v1.00

Hubitat Elevation device handler for the Pixelblaze addressable LED controller.

12/24/2019 Version updated to 1.0 - this is a major update

What is a Pixelblaze?

For information on the Pixelblaze, visit its home: www.electromage.com

Pixelblaze is an ESP32 based programmable LED controller with a fast
fixed-point integer Javascript-like interpreter built in. It's very easy
to create and save complex lighting patterns, animated or not.

What can I do with this driver?

This driver gives the Hubitat basic control over the Pixelblaze - on/off, brightness,
get pattern list, set active pattern, etc.. It works with RuleMachine, so you can
coordinate the Pixelblaze with your other home automation devices.

For example I have mine set up to automatically turn on/off depending on ambient light level,
in sync with the rest of my Hue setup. I also have it run a nice candlelight pattern for a few
minutes if a motion detector sees somebody coming downstairs in the middle of the night.

What's New in this Version (1.00)

Alternate on/off method

You can now choose between two methods:

1.Set specific patterns to use for on and off states. The advantage of this method
is that it gives you complete control over what "on" and "off" actually mean.

2.Use hardware brightness to switch on and off. This has the advantage of
being completely pattern independent. It works like... an on/off switch.

To preserve compatibility with the previous version, the default is method 1 - using
patterns. To switch to the new method, just unset the "Use Patterns for On and Off"
switch in preferences, then save preferences.

Lazy Connection

Connects to the Pixelblaze via websocket only when necessary to keep traffic and load on
devices to a minimum. You are connected only when you issue a command or request status.
After a short period of inactivity (configurable via a constant in the code), the connection
is closed.

Auto-reconnect and Sync

The device handler now periodically polls for status and configuration. So if you use the
Pixelblaze's web interface to change settings or edit patterns, or if the Pixelblaze
(or the Hubitat) should go offline, connection will be automatically reestablished, and
hardware state and pattern list resynced.

It's not instant - if you're actively working on things and need connection now, use the
"Initialize" and "Get Patterns" buttons, but if left unsupervised, the device handler will
quickly return to its normal working state.

Improved Pattern Handling

Quality-of-life improvements. "Set Active Pattern" is joined by "Random Pattern", "Next"
and "Previous" to make switching and exploring patterns a litte easier. I've also exposed
the Pixelblaze's internal pattern sequencer, which rotates between
all available patterns on a timer.

SetVariables (replaces SetVariable)

The SetVariables command takes a json-formatted string composed of the names and values
of variables exported by the currently active pattern. See readme.md in the repository
for details and example code.

To Use

Set up your Pixelblaze. Take note of it's IP address.

On your Hubitat Elevation's admin page, select "Drivers Code", then click the
"New Driver" button. Paste the Groovy driver code from this repository into
the editor window and click the "SAVE" button.

Create a new virtual device on your Hubitat, name and label it, and select
"Pixelblaze Controller" as the device type. Save your new device.

Click the new device on the Hubitat's "Devices" page, and enter your Pixelblaze's
IP address and port number (which should be 81) in the provided field.

If you are using on and off patterns (selected by switch in device preferences),
you will also need to enter the names of the patterns to use for the "On" and "Off"
states. You can use any pattern stored on your Pixelblaze.

For the "Off" pattern, I just wrote a quick pattern that does
nothing when called to render pixels. Like this:

   export function render(index) {
     ; // do absolutely nothing

But again, you can have "On" and "Off" do anything you like!


Correct link

What are you using for the led strip ?

Thanks for fixing my link! I really should've been a bit more patient.

I used semi-random items from Amazon, based on specs, reviews, and great optimism. The LED strips are 5 meter BTF-Lighting SK6812 RGB+Natural White with 60 LEDs/meter. They're extremely bright. The colors are reasonably close to Hue bulbs. Power comes from two Letour 5v 30A DC power supplies.

1 Like

Hey, i'm looking for a sk6812 RGBW integration solution and seems that I found it.
Do you know if this driver can handle multiple PixelBlaze? I read the how to use, and i saw that it requires the IP. So I think it does. I just want to be sure before buying it.

Hi! Sorry for the delay, and thanks for asking!
Yes, you can run multiple Pixelblazes (on different IPs, of course) by installing multiple instances of this driver. That said, I'm still trying to work out how best to handle all the things an addressable lighting system can in do the Hubitat model. I'm currently working on a composite driver that potentially loads different sub-devices for each Pixelblaze pattern. For example, here's a pattern that divides the strip into multiple zones, each synced to the nearest Hue bulb:

And here's our current Halloween lighting:

The driver is a couple of weeks away. I got lazy and protoyped the Hue synchronization and animation control on another computer in Python. At this point, I'm very open to ideas as to how I can make this setup work better and do more cool things with the Hubitat. :slight_smile:

1 Like

Ok that flame effect is badass !!

I found this strip. I'm pretty sure it would work ?

It looks like it will. You may have to play with the pixel timing options on the Pixelblaze a bit for optimal refresh rate.

FWIW, mine are:
Addressable RGBW LED Strip
(Ugh... The price has gone up since the tariff thing started. And how do you get the nifty Amazon link box to appear? )

I think URL previews show up when they are on their own line :slightly_smiling_face:

You can get sets of WS-2811 lights for $10-$20/5m, still, if you don’t need such a high density. I use those around my house.

FWIW, I have a bunch of addressable LED strips in my house and I've found the BFT lighting to be really good. They are pretty resiliant and the colors are very true, not like some other strips I've bought. I was thinking of trying either the SK6812 or the WS2815 next. The backup data line on the 2815's is very appealing. But damn...they are expensive.

These are the ones I used last.

In my experience, for uplighting or biased lighting, 30 led/m is more than enough. If you're trying to use as a primary light, stick with RGBW and get 60 led/m. Would you agree with that?

1 Like

Oh man. I really want to see how you’re implementing these... :cowboy_hat_face:

These went into the Hyperion for my living room TV. As well as a small strip for lighting under the coffee table. All are controllable as Hue Strips for simple color/CT/dimming or through a program called McLighting for animations and stuff. I build a protoboard for the tv ones that is really pretty intricate. An Arduino, 2 Wemos D1 minis and a ESP-01. After much debugging it is finally working flawlessly. I haven't had a chance to finish fine-tuning the color of the leds but when I do I'll upload a video.

I'm very into addressables at the moment. I also just did a project for my car with6 neopixel sticks, 2 under the dash on each side, 2 under the seats facking forward and 2 under the seats facing back. THAT took a lot of work. But all the solutions I found online sucked. This does exactly what I want. The board even broadcasts it's own little wifi hotspot so I can control them. Gotta love the ESP8266. If i had any ability to code, I'd use an ESP32 and develop a bluetooth app. But also, not yet.

1 Like

Ah nice!! Not to get off-topic, I have a dreamscreen and a few other strips. One of them is year-round for outside our house. I’ll DM you—I’d love to hear more

Boy not cheap at all. I guess its because of the natural white -- it's a RGBW

Cool! TV bias lighting is on my list too. And a bunch of outdoor stuff, and many revisions to lighting in the house... Addressables are a lot of fun.

I went with the 60 led/meter strips because they are close in pixel density and brightness to the latest generation of Hue strips. It turns out the BTF strips match Hue colors very well. I didn't know when I ordered, so was all set up to take a series of pictures, compare colors and build a remapping function. Glad I didn't have to! And they were really not that expensive when I got them. I'd still recommend them but there are bound to be less expensive strips that'll do fine.

First and foremost I would like to thank you for taking the time to write a driver and share it with this awesome community!
I had actually purchased a pixelblaze and funny enough, the same exact LED strips you're using before I started looking into using this with my home automations.
When I found this thread, I was a happy camper.

Long story short, I followed your README and set up the driver code, virtual device, and filled out the appropriate information (I think), but am having no such luck getting it to function.
I noticed in the IP address section, it says to include port #.
Do I have to set up port forwarding on my router for the pixelblaze?

I apologize if I'm missing something simple here as the custom drivers are new territory for me.
Thank you in advance for your help.

Check the pixelblaze setup docs, but I'm pretty sure the port number is 81. So, the IP address you enter in the driver setup box will be in the form (of course with your IP address in place of the 192.168...) If it doesn't connect immediately, on the Hubitat driver page, press the disconnect button, then the reconnect button, and everything should be OK. I wouldn't expect you'd have to change anything on your router, unless you know it's blocking ports on your LAN.
Also, be sure you've set the patterns for on and off in the driver.

(of course, this is assuming you've got the pixelblaze set up on your wifi -- if you don't, let me know, maybe I can help. )

Just an update -- I still have a new driver on the way, but I've been rethinking how I handle LED strips at home. I got tired of using multiple lighting control apps, and now everything goes through DIYhue, so I can use the factory Hue app for all lighting. I've written a protocol remapper that can convince DIYhue that virtually anything is a Hue device, including zwave motion sensors and bulbs attached to the Hubitat. It's running (as of yesterday), but twitchy atm. I'll post as soon as I think it's solid enough.

Thanks for the prompt reply!
I went back through the "standard" setup documentation and didn't see the port listed, then lo and behold in the "advanced" section under websockets, there it was, port 81...Doh.

It did indeed connect immediately and it works great.
Having the ability to set the global brightness level and active pattern based on motion, time, or literally any trigger is phenomenal.
Already made some simple motion rules with it that perform as expected in 30 minutes of playing.

A couple more basic questions for you.
What are you using getPatterns and setVariable for?
After using getPatterns, I see a pattern list in the device configs, but am unsure of what to use it for.
Along the same lines, when would I find myself needing to disconnect, reconnect, or initialize in normal use?