Quick Review of Inovelli’s LZW45 Light Strip

I’m looking for a pair of light strips I can use to make cool effects in my house! Since I have a lot of other Inovelli gear, I figured I’d start with their LZW45 light strip first.

Adding it to my ZWave network was basically like every other Inovelli device. Set the hub to inclusion mode, and then tap the action button three times quickly. I thought it was neat that this giant light strip pulsed blue while it was doing the inclusion process and then went to green when it was done, just like every other Inovelli device.

Getting it set up in Home Assistant is a bit tricky. I’m still using the Open ZWave 1.4 stuff, which is pretty old at this point. The directions on Inovelli’s website are mostly correct, however. In a nutshell, you need to update your local open-zwave DB with their latest definition files before you include it into your network. The directions on how to do this are in the installation guide. Here’s the version of it I’m using out of my own config!

After I got it into my Home Assistant config, I noticed that a light entity wasn’t created. I did some searching and figured out that this is a known issue with OZW 1.4, and the workaround for it is on Inovelli’s forums. I made the change listed here, and everything started working fully. Yay!

To be able to control it, I used the script from this forum post. (Take a peek at my own config, too!)

One that script is enabled in HomeAssistant, you can call it from Developer Tools -> Services from the UI. Here’s the service call I used to set it up for the Aurora pattern:

service: script.lzw45_pixel_effect
data:
  service: zwave.set_config_parameter
  lzw45: light.inovelli_lzw45_light_strip
  effect: aurora
  brightness_pct: 60

Is the this light strip I’m looking for?

I don’t think so. I’m going to keep on looking. I love how easy it was to get going, and I really like the idea of having a dedicated controller that’s made for it. Controlling a light strip over ZWave is awesome, too.

The problem is, to me at least, that it’s not very smooth. For the single pixel effects (like chase), it looks great, but what I’m looking for it more along the lines of the Aurora effect. When it’s trying to address all of the pixels at once it gets pretty laggy and flickery.

For the $50 I paid for the light strip and controller, however, I think it’s pretty good deal, and I’m gonna find a neat place in my house to use it!

Recruiting via GitHub and Unintentional Biases

My GitHub Commit History

I would like to talk about unintentional basis for a moment.

The above chart is my own commit history (on my personal account) on GitHub right now. Not a single one. Pretty terrible, right? Some people in our industry think so. I linked to this blog post only because it’s the most recent one I read – I’ve read others like this, too, recently.

Now, taking this with a grain of salt because it’s written by a recruiter with a decade of experience working at RedHat, I want to talk about two points.

The first, and least important, is that GitHub is just one of many Version Control Systems in wide use today. To claim that it’s the “social network of code” is very misleading. It’s popular with open source projects… but lots of really talented and amazing engineers work on proprietary systems that aren’t tracked in GitHub. I happen to be one of these.

VCSes are, by their very nature, suppose to be boring. They’re just a tool for tracking changes and promoting collaboration between engineers. Tools like this date as far back as to the 1970s. There’s a bunch of them on the market. They’re designed to get out of the engineer’s way, and let them focus on code.

I work on a legacy codebase at work that pre-dates GitHub by many years. We have a well established set of processes and scripts built around the VCS we use, and they’re working for us. It’s fun to think about adopting a new one, but let’s be honest, our current one works, and we’d rather focus our efforts on making cool things. We don’t want to take the productivity hit fixing something that isn’t really broken.

I work with some amazing engineers who create awesome things, but you wouldn’t know it by looking at our GitHub commit history. (I’d rather you look at the stuff we produce instead!)

 

The second point, however, is far more important.

This blog dances around it (most likely wisely, because this comes up a lot), but I’ve read several that suggest that “always be coding” (ABC) means that it doesn’t matter if you work on a proprietary codebase that’s under lock and key – all good engineers will spend their weekends and evenings writing code as a side project.

This is crazy.

I work with some really talented engineers whose “side projects” include things like “raising a family.”

Just in my circle of friends and coworkers, I know people that do things after work hours like participate in community theater, volunteer at a suicide hotline, be a parent to multiple children, care for animals in a shelter, contribute to grassroots political campaigns, write novels, and help create safe spaces for closeted LGBT people that are in need of someone to talk to. Each of these examples is from an amazingly talented and awesome engineer that any company would love to have on staff – but you’d never know it by their GitHub contributions.

 

Don’t let a tool like GitHub inject unintentional biases into your recruiting processes. It’s a pretty slick VCS, yeah, but remember that it’s just one of many… and you’re going to miss out of some amazing people.

April ❤