Over-engineered LED strip controller

After some more experimentation, it seems like these components are very sensitive to input voltage. It's alleged that they want anything from 4.5v to 20v, but the tirggering behavior is pretty erratic for every power supply I've tried from 5.5v up to 12v.

They seem to work best (most stable) when powered by the 3.3v pin from the NodeMCU board. Hmm. In my note yesterday, I forgot to mention that. Actually, I didn't even notice until I was looking at my breadboard this morning. It's one of the zillion things I tried.

I guess if I end up using the HC-SR501 units in the project, I'll have to select the specific ones by testing them with the voltages I have available (which will be 3.3v, 5v, and 12v). Maybe the AM312 units will be more consistent.

Another thing.... Sometimes, after getting my 2-3 seconds of HIGH for motion detection, the signal will go low for 5-7 seconds and then mysteriously go high again for another 2-3 seconds. That won't make too much difference for this garage light project since the lights will still be on from the initial trigger.

I've spent some time looking into Lua. I think it will meet my needs for this project.

As with most languages, the authors have made some choices that I wouldn't have made. However, there seems to be at least a reasonable rationale for the things they decided. And they seem to have made it so that you can get close enough to things you want the language to have. For example, Lua doesn't need semi-colons to terminate statements ... but you can put them in there if you want to. Yay! They don't have real classes and objects, but you can make your code look a lot like it does.

I was planning to do most of this code in an event driven way, and the Lua libraries for NodeMCU make it pretty easy to register callback functions to handle interrupts. On the other hand, the standard libraries are not especially rich in devices (like Arduino-land), but I think that will be OK.

Oh, yeah, it's got GC memory management. I've spent enough time debugging mismatched malloc and free, thank you, so GC is a major plus for me. I doubt that I will have that many collectible "objects", but it's nice to not have to worry about it.

Today was a pretty frustrating day. It took me way too long to get my passive IR motion detector working correctly, though I was victorious in the end.

I think the most common module is HC-SR501 or something that looks like it. I got a handful of them to use in this project. My main reason for selecting that component specifically is because of the abundance of sample wire-ups and code fragments. I set about doing the same thing ... read the PIR and show what I got on an LED.

Here's the thing about these: I guess a lot of different places produce them, and the specs vary a little bit. Most commonly, there is a variation on what operating voltage they will accept (though, luckily, they all seem to put out ~3.3v for the signal). The ones I have didn't come with a spec sheet. I have what it said in the description on eBay, but that's not always accurate.

Let me cut to the chase: I spent hours trying to get rid of spurious triggerings. I tried decoupling the input voltage, I tried pull-up and pull-down resistors on the signal, I even wrapped the entire sensor component in aluminum foil. No matter what I did, every 15 seconds or so I'd get a few seconds of high signal indicating motion detected. These things have two pots and one jumper setting. I tried all kinds of combinations. I tried swapping around the Vcc, ground, and signal wires just in case the silk screen was wrong.

Finally, the thing that worked was turning the sensitivity pot all the way down. That seemed to do it. No decoupling caps, no resistors, just the board and some wires. I don't know if I just got a bad batch of if they are all like this.(I did have one that was from another source [another source for me; could have been assembled in the same factory line], and it was the same.) What's the point of having a sensitivity pot if it only works when it's turned all the way counter-clockwise?

Along the way, I found some badly translated operating instructions and some other instructions that were just plain wrong. Here is what I deduced from a lot of pondering.The jumper controls repeatable or non-repeatable triggering. I found those terms a little confusing. "Repeatable" means the signal stays high as long as motion is detected; when motion is no longer detected, the signal goes low after a short time. "Non-repeatable" means the signal is made high for a short, fixed duration. After that the signal goes low and won't go high again until there is a period of no motion and then motion is seen again. Even with non-repeatable, it's not just a single pulse; or rather, it's a single pulse of a couple of seconds.

I'm a little leery about the lack of precision (or something like precision) with the HC-SR501. I've ordered a different type of PIR that goes by the designation "AM312". The specs and form factor are somewhat different. We'll see.

Earlier I said, "I don't plan to use Lua". That's mainly because of a personal bias against languages that don't really add anything except their own flavor of syntax and their own crowd of cheerleaders. I've saved myself a lot of tiresome dead ends that way. For example, if a language has built-in "dictionaries" or "maps" or whatever, it's a big yawn to me because I can get the same thing is most other languages by just calling a library of some sort.

But there is no ignoring languages that have a rich ecosystem. For example, the Arduino environment has tons of C/C++ libraries for doing all kinds of things. So, even though it's a somewhat "non-technical" environment, it is really, really handy for saving a ton of grunt work.

I've been looking through the eLua APIs and reading some of the claims made by the Lua gang. If what they say is true, then it sounds pretty compelling. Especially that it plays well with C/C++, so there is always an out if I find something it doesn't have.

I'll be considering the ecosystem differences and synergies of the Arduino and Lua camps as I get a bit closer to the software layer.

I got this idea while browsing the Lua API for nodemcu (although I don't plan to use Lua).

Besides the normal operational inputs (PIRs, rotary encoders [including switches]), there are no other inputs. I could use some of these things to activate some kind of configuration UI:

• long press of the rotary switch
• double click of the rotary switch
• triple click of the rotary switch (hmm, seeing a pattern)
• basically any combination of long and short presses of the rotary (analogous to Morse code)
• I could also distinguish between the master rotary and a remote rotary
• feedback could be given via the pilot LED or the lights themselves (most likely some series of blinks)

Given this idea, I don't know what I'd actually do with it. Most configuration will be controlled by constants embedded in the code, and updating them is just a matter of downloading a new firmware. I guess this could save me the awkwardness of firmware updates after this stuff is installed.

OTOH, I can also run a web server via the built-in wifi, so maybe this is a pointless idea after all.

I've reached a bit of a cross-road with competing goals. In starting to lay out the schematic, I've started to run short of GPIO pins on my nodemcu. I'm not completely out, but I'm running low. (I had originally planned to use a Wemos D1 mini because I had some on hand, but that ran short of pins right away.) I guess I knew this was coming since I can count, after all, but now I've got to deal with it.

I think my choices are:

1. Reduce the scope of some of my desires. For example, stick with only 1 remote switch instead of allowing for 2.
2. Switch to another microprocessor board with more available GPIO pins.
3. Find some off-chip way of expanding the number of pins, either using the otherwise-unused SPI pins or some other helper chips.
4. Combine some of the signals with simple boolean gates. For example, I'll have 2 PIR sensors, but I don't care which one (or both) triggers.
5. Put controllers in the remote sensors and/or switches and design some simple protocol for those independent brains to talk to each other.

I'm going to go with choice 1 for a couple of reasons. First, this is partly a learning exercise, and maybe I'm already learning enough :-). Second, complexity kills, and this is already pretty complicated. Third, I expect the software to handle the sensor inputs (which is the majority of the pins) with interrupts, and that's simpler if they don't go through some helper chip. I'm skipping item 4, at least for now, because I have some hazy ideas for treating things distinctly, which I won't fully figure out until software time.

In the US, a single-gang electrical box has an interior size of about 2 7/8 inches height and 2 1/8 inches width. That size can vary a little bit because the thing that's actually standard is the space between the top and bottom screw holes for the face plate, which is not included in the size I just mentioned.

I may design a custom PCB so I don't have things loose inside the box, and I think that size rectangle will give me plenty of space for the layout. If it's too small, I'll either have to go to a double-gang box or maybe sacrifice some features to recover board real estate.

That's all for the main switch box. The remote switch boxes won't have much in them, so they'll easily fit in a single-gang box.

I have some face plates that have a single round hole for an RG-59 or RG-6 connector for cable TV. I'm hoping that the size is a good match for mounting the rotary encoders, but I haven't tried it yet. I did find some nice adjustment knobs for the rotary encoders on eBay. I'd tell you where to get them, but they seem to be some kind of surplus "old stock", so you probably can't get them anyhow. They are made to mount on a "D" shaft, which seems pretty rare these days. Good for me because that's exactly what my rotary encoders have.

For the ceiling mounted PIR sensors, I'm thinking that I might be able to find some pretty inexpensive plastic light fixtures. I can take the guts out of them and then mount the PIR fresnel lens onto it somehow while hiding the actual PIR board inside. I don't want it to look too ugly, but it won't have to be perfect since it's up on the ceiling where people don't tend to look.

I haven't tested all of the electronics, but I have been thinking about some of the things that I want to have this do. It's got to be complicated enough to keep up my own selfish interest, but it's got to be straightforward enough that someone else in my household does not poison me because of it.

• At full power, these things are pretty bright. I want to have a dimmer control (PWMs).
• The dimmer will be combined with an ON/OFF switch so that the previously-set dimmer level is remembered. I'm not completely sure about this, and I might change it to having a comfortable default dimmer level when the lights are turned on.
• Because of multiple garage entrances, I want to have switches in multiple locations (at least 2, maybe 3) that can do the same things that the main switchbox can do.
• Each switch should have an LED or something so it's easy to find in the dark. This is called a pilot light, I think. (I probably won't use natural gas :-). )
• The place where people work on things is not necessarily close to the switches, so I want to be able to place the motion sensors (PIRs) in other places. I'm thinking of ceiling mount, but I'm not sure if I will need 1 or 2 sensors.
• The lights coming on or going off should be fades of some short duration.
• When the lights are going to turn off (because of the timer and no motion detected), it should give some kind of warning. For example, maybe 30 seconds before turning off, the lights gently blink. This is so someone quietly doing something is not suddenly plunged into darkness.
• I haven't figured out yet if I want the timer to be some fixed duration or if I want to be able to adjust that with some kind of control. Based on how I observe others using adjustable timers, they just pick the max time anyhow. So maybe I'll skip the complexity.
• There will be a 12V DC power supply for the LED strips. With a simple power supply module, I can step that down to drive my microprocessor at 5V. Because I am not sure what the future might bring, I may provide a jumper option to have the voltage out to the load be either the same as the input voltage or be the same as the stepped down voltage. I'm really not sure if it's worth it or if I just want a reason to have a jumper.
• I plan to use rotary encoders for the dimmer control. There is probably some cut-off for the PWM where the LEDs don't work stably or have too much flicker or whatever. And, obviously, there is a max PWM duty cycle of 100%. I want some kind of feedback to the human that they have reached one of those points. Maybe I'll blink the pilot light for feedback.

That's all for now. I'll revise this list later as my thinking evolves.

For a long time, I have been looking for the perfect light switch. (I do that in my spare time when I am not busy looking for the perfect remote control.) It's easy to find most of the features I need, but not combined into a single switch. Since the LED strips are 12V, standard wall switches (US 110-120v) won't work out anyhow.

Here are the features I am looking for:

• Dimmer
• Timer
• Motion detector
• Pilot light ("find me in the dark")
• Three-way (or more) operation

It's also fairly easy to find those things pre-packaged to work with LEDs, but, again, not all in one little switch box or even a combination of little boxes that work together the way I want.

I'm pretty sure I can build something with a microprocessor and have it all fit fairly neatly in a standard US in-wall electrical box. I think I can also put my controls on a standard switch-plate blank for that kind of box, but if I can't I might 3D print one. I won't be able to completely hide the wires into and out of the controller, but it should look nice enough for a garage.

This is a bit of a learning exercise for me since I'm not completely sure of some of the pragmatic aspects of the electronic interfaces ("do I need a decoupling cap?", "should I put a diode there?"). I am mostly borrowing ideas from things that people have already built and explained. It's amazing how much it simplifies part selection when someone has already chosen.

Here are just a few details about the lighting hardware:

• I put up 2 of the 15 ft (ok, ok, 5 meter) strips and used an adapter to plug them into the same ceiling-mounted sockets.
• Holy cow! It's incredibly bright. I have to wear sunglasses in there now. For now, I can control them with the existing wall switch.
• The LED strips I choose were SMD 5630, "warm warm" or "natural warm" color, 60 LEDs/meter.
• Each strip draws about 40-45 watts through the A/C power supply (measured, not theoretical). Someday I will figure out what that means for RMS and DC and such. Today is not that day.

Next post, the reason for the controller complexity....