Lightshowpi (and others) integration: sACN/e1.31 proxy

[zranger1]

I’ve just posted code for a Python 3-based sACN proxy to my repository here:

zranger1/pb-sacn-proxy

Here’s video of lightshowpi on a pi 3b+ running 8 channels of normal lights plus a spectrum analyzer on a 16x16 Pixelblaze matrix via the proxy.

At this point, the proxy code is basically a library+example code in a single script. Some technical knowledge is a must. There’s no UI, but with a little rearrangement of the code, you can drive multiple Pixelblazes from the same proxy instance, or run multiple instances forwarding different sets of DMX universes. It supports up to 480 RGB pixels per Pixelblaze, and allows you to manage network and Pixelblaze bandwidth by regulating the outgoing frame rate.

lightshowpi configuration is a fairly complicated thing on its own. I’ll be improving the docs over the next couple of days to help with this, and I can probably answer some questions, but most likely I’ll be doing the same thing you will – staring at those very verbose configuration files, making my best guess, test, rinse repeat… (and now I have no more excuses. time to go hang those lights!)

[wizard]

@zranger1,
This is awesome! Thank you for putting this together!

[zranger1]

Right back at you @wizard – this wouldn’t have been workable at all if Pixelblaze’s websocket handling wasn’t as fast and solid as it is!

[aiotea]

Hi @zranger1,

This is a great post to see … I’ve just looked through your github repos and see so many rad things for pixelblaze! Thank for all you share here.

I’ve gotten the RGB SACN Listener running on my pixelblaze, but was hoping to send the SACN signal from regular desktop lighting software that supports SACN (E1.31) … I’m new to this ecosystem tho, and wanted to ask if something like this is possible via what you’ve written? Do I have to run sacnproxy.py locally on my laptop and just route my lighting software there or is it more complex ?

Thank you

[Scruffynerf]

Yes, just run the proxy code locally on your laptop or a Pi, and connect to it.

[aiotea]

On the laptop (mac), it’s giving me an error “invalid syntax” on line 263 of pixelblaze.py, which is…

            hw = {**hw, **p2}

I’m not familiar enough with python to know how to fix this… Any suggestions?

[Scruffynerf]

What version of python are you using?

[zranger1]

Good catch, @scruffynerf! The proxy code requires a relatively recent Python 3. That line of code uses a Python 3.x-only feature to merge two dictionaries.

Python’s versioning situation is strange. Official Python is on version 3.9.x now, but the legacy 2.7.x versions are still absolutely everywhere because there’s so much existing code that requires them. I don’t know what versions of Python come with Macs, but like most Unix-ish things they may well have both a 2.7 and a 3.x version.

One way to find the Python version is to use the terminal command:
python --version

If it returns something like Python 2.7.15 , try the command:
python3 --version

to see if you’ve got Python 3 installed. To run the proxy, it’ll need to be 3.4 or newer. (Newer is better - I actually wrote it using 3.7.7, the latest release is 3.9.something…)

If you do have Python 3, just start the proxy by typing python3 sacnproxy.py instead of python ... If you don’t, you can get it from www.python.org.

[Scruffynerf]

just a recommendation: if you have a mac and doing CLI things (or even non-CLI things), using https://brew.sh/ is game changing. In this case, you can install python directly via brew, BUT I’d recommending using pyenv (so install pyenv via brew, then use pyenv to install python 3.x.
Pyenv allows you control which python you use where, install multiple versions, and more.

So you can easily add support for this proxy to use a particular version that works for it, and not worry about some other code you use elsewhere that requires a different version.

(pyenv also works on linux too)

[aiotea]

Thanks for the help… I’m working through it now…

A quick question… will this allow me to control multiple pixelblazes independently? I know with ArtNet, I can send to individual IP’s, but am not sure if I can with SACN yet… And if so, would I just specify multiple IP’s on line 323 of sacnproxy.py?

My goal is having the pixelblazes controllable as separate fixtures…

[zranger1]

@aiotea, let me just throw out a few ideas here…

The Python proxy code is a proof-of-concept. It’s meant as a springboard to give interested programmers an idea what might be possible, and a basic framework to build on. So, yes it is possible to get it to send data to multiple destinations. But it would take a moderate amount of programming to do it. If I were trying to run a show or an installation from a single central program that sends Artnet/SACN/DMX data, I would definitely not do it this way.

Given a bunch of Pixelblazes, I would get one of these: Pixelblaze Arduino Programmer, and reflash the Pixelblazes with WLED, LedFX or something else that explicitly supports the protocol you want to use. (All these programs come with instructions for flashing. One thing though – if you go this route, be sure to save the original Pixelblaze software image in case you want to restore it at some point.)

The Pixelblaze’s software is designed as a standalone user programmable controller. It is kind of awesome that way. There’s really nothing else like it, but it is not a good fit as a simple data receiver. However, Pixelblaze hardware still has many advantages - flexible power management, polarity protection, excellent LED driver circuitry - even if used with different software.

(Another possibility, if you decide to keep the Pixelblazes as they are, and need to synchronize and control patterns across multiple Pixelblazes, is of course, Firestorm)

[aiotea]

Awesome @zranger1 thank you for explaining…

I totally understand this is a proof of concept, and it’s great to know I can re-flash these if needed… I hadn’t seen that programmer hat.

I need to do more research, but unfortunately, I think I need more of a “hammer” …

[zranger1]

They do exist! The amazing folding screwdriver/hammer! (from my grandfather’s tools - probably dates from the mid 1950’s. Pretty good screwdriver, not-so-great hammer)

[wizard]

@aiotea ,
Keep in mind E1.31 is in the future for Pixelblaze. Possibly another network protocol first, like Open Pixel Control. You aren’t alone in wanting a high quality LED controller like Pixelblaze but with direct pixel capabilities.

How many pixels do you intend to use per PB?

[aiotea]

Sorry for the delay in reply…

It depends on the project, but the one I’m doing now would be great at about 1400 pixels.

[Scruffynerf]

Protocol comparison:

http://www.3waylabs.com/ddp/

DDP is being talked about in many circles (WLED and LedFx for example) as less limited than e1.31

Also Dave of Dave’s Garage just released his NightDriver code, haven’t yet looked at protocol he picked. Looks like he rolled his own. But that said, his open source plan is take contribution so I suspect support for the other standards will likely happen, just because they are standards.

[wackazong]

To revive this discussion: I am also looking for a way to use PB as a simple pixelpusher in addition to the pattern engine. This would allow me to use the same hardware for two different architectures, which would be awesome.

I would be willing to do a PR for a UDP-based pixelpusher protocol (would most probably be DDP or Artnet, right?), as this would be much more efficient, right? It should be possible to make PB act as an DDP/Artnet receiver, or are there some difficulties with that?

Thanks for pointing me to where to start.

@zranger1, which framerate did you achieve with your proxy solution?

[zranger1]

@wakazong, this version of the proxy was written for Pixelblaze v2, which had a slower processor – it’s artificially capped at 30 fps in the Python code.

On a v3 Pixelblaze, with the cap removed, it’d be dependent on LED count. I’m reasonably sure you could drive a few hundred LEDs at 60fps or close to it.

[wackazong]

Ok, great. That sounds promising. I will test that. Thanks.