[RELEASE] Pixelblaze addressable LED Controller Driver v1.00

Hubitat Elevation device handler for the Pixelblaze addressable LED controller.

Current Version: 2.0.0

https://github.com/zranger1/hubitatpixelblazedriver

What is a Pixelblaze?

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

Pixelblaze is a programmable controller for addressable LEDs. It supports most common
LED types right out of the box, and comes with many different effects and the ability to
download more. It also has a fast Javascript-like development environment built in, so
it is very easy to create and your own colors and effects.

This driver gives the Hubitat control over the Pixelblaze as though it were a light bulb. You can control on/off, brightness, RGB color if the pattern supports it, etc.

In addition, you can easily change effects, and if you install the optional "Multisegment for Automation" pattern (see the readme.md), you can subdivide your LED strips into up to 12 independent segments, each acting as an independent RGB light, with effects.

It works with RuleMachine, the Maker API and other apps, so you can coordinate the Pixelblaze with your other home automation devices.

11 Likes

Correct link

1 Like

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:
20190731_212821_1

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.

Hi!
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 192.168.1.104:81. (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?