Over-engineered LED strip controller

"Thanks for your valuable service. You have made immense contributions. You are well on the way  to creating something great. Unfortunately, due to ... mumble, mumble, mumble ... we are forced to make some hard decisions. We are re-prioritizing our efforts in different areas. To better serve our customers, re-align with our stakeholders, blah, blah blah...."

Chairman: Doctor, you are genius!

Dr. Poppover: Of course.

Chairman: You are national hero!

Dr. Poppover: Natch.

Chairman: You are under arrest!

Dr. Poppover: Eh, why?

Chairman: You know too much.

Dr. Poppover: Oh.

Well, I learned (or re-learned) a heck of a lot by working on this project over the course of several years. I've decided to break my pretty balloon and put all my toys away, at least for this project. Some things have changed over the 4+ years since I started it, and I'm not even talking about the crazy number of times I changed my mind about details of the project itself.

• After a few years of service, the inexpensive LED strips I bought have started to show small areas of blinkies and fade-out. I haven't had to replace any sections yet, but I've become skeptical about their lifetime.
• Due to the continued accumulation of detritus and the consequent narrowing of walking pathways in the garage, the need for good and automatic lighting is becoming more and more important to me every day. I'm afraid they might find me under a heap of non-automotive possessions before I can finish the project.
• Alternatives to LED strip lighting have become better, cheaper, all-around nicer in recent years. I bought dimmable LED tube replacements for some fluorescent bulbs probably more than 10 years ago, for an outrageous price, and their dimmability was pretty horrible. My local utility company now sells 4 foot dimmable LED tubes for US$5 (including a US$2 rebate per tube). They are "direct replacement" so can be used with or without ballast. I have some, and they are excellent.
• While wandering through my local home center, I saw a clearance item of some 4 foot tube fixtures. Each can hold a pair of tubes. They were normally around US$35 (comparable to others not on clearance), and the clearance price was under US$7. As a Hackaday reader, it is my sworn duty to scoop up such bargains whether I need them or not. I visited a couple other locations of the same home center and bought all I could find. (I put one of these up in my basement where there was just a bulb before. Now I can see all the spiders. Yikes.)

The most important thing that changed, however, is that I have switched my approach to home automation from being a series of one-offs, which are a combination of learning experience and disaster in the making, to a more organized approach. My weapon of choice now is Home Assistant, a widely used open source project. I got interested in this approach when I started to look into how I could keep historical records of things like temperature readings and then make cool visualizations of them. In theory, I could do all that from scratch and/or by cobbling together various off-the-shelf things, but who has that kind of time?

(An aside about Home Assistant. They have a sort of middle-ground problem. There are tons of things you can do by just following their recipes or click-this-click-that in the web UI. They also have a very sophisticated architecture that makes extremely complex things possible without requiring fundamental changes in the framework. The middle ground problem is that there is a hard road in getting from that first stage to the last stage. If you are a programmer and are willing to work at it, you can figure it out.)

I installed the motion sensors as originally planned. I ran the wires a while back, and they have just been dangling in the air since. You need three wires to operate a PIR sensor (power, ground, signal), and I had originally planned to use a fourth wire for lighting an LED co-located with the sensor so I could see when each triggered. I got lazy and skipped that. The professional-looking mounting you see in the image below is good enough for something that lives in the garage.

I installed a third motion sensor on the wall near the walk-in door and near the control box. That was so the lights would come on well before someone got into the detection area of the ceiling-mounted sensors. I don't think I really needed that. With the sensitivity of the PIRs turned to maximum, the ceiling-mounted sensors cover pretty much the whole garage and even significantly overlap each other. 

I have a menagerie of different PIR types (including some really nice, but expensive, ones from Sparkfun), in the end I used the cheap ones that you see everywhere when you look around for PIR sensors (a rectangular board, a square white lens cover, two adjustment pots, and a 3-pin jumper). These are usually advertised with a maximum detection range of 5m-7m, which was correct for the ones I used. One of the pots controls a timing factor, which I found to be so unreliable and weird that I chose to set it to minimum and let the controller sort it out from the triggerings. Although these cheap PIR sensors from many sources look remarkably similar, they are prone to having reversed or wrong controls or markings, so direct experimentation is pretty much a necessity for getting them to work. Tutorials about them are likely to assume they work the same way as those the authors had on hand.

Instead of the gold-plated control box that I originally planned, I put an ESP8266 into a little box I had on hand. The box is intended to be used as some kind of surface-mounted junction box for things with keystone jacks. It has knock-outs for 6 ports, and I used 3 of them to plug in the wires from the motion sensors. Inside the box, I put the ESP8266 on a tiny bread-board. That gave me enough bread-board area to wire everything together with dupont jumpers. It's a bit of a rat's nest, so I'm hoping to never have to remove the cover ever again; if I do, I'm sure it will stop working.

I also mounted an LED through the cover of the box and wired it to a spare GPIO pin on the ESP8266. The LED is lit when any of the PIR sensors raises a "detected" signal and turns off when that sensor withdraws its "detected" signal. Ditto for the on-board LED (because, why not?). This was extremely handy for determining the scope of the PIR sensors as I moved around the garage. It's not a perfect implementation because one sensor can turn the LED on and another sensor can turn it off while the first sensor is still "detecting", but I was too lazy to do anything about that. I thought about using separate LEDs for each PIR sensor, but, again, too lazy (and I didn't want to open the control box cover).

Last, but not least, I added a BME280 climate sensor (temperature, pressure, humidity) as part of my collection of having them sprinkled around the house. That was part of the original project plan. In the interim, I had a separate ESP32 reporting that info; that device is now harvested for other uses.

The logic for the ESP8266 is written as an ESPHome configuration. I've included that file, garmotion.yaml, in the files section of this project. It sends the "detected" signals over MQTT to my Home Assistant server. With 3 PIR sensors and the PIR hold times set to minimum, the "detection" signals are very chatty. That's not any kind of performance problem for this home-based system, but it felt inelegant to me. I did 2 things to tone it down. First, I implemented what ESPHome calls a "template sensor", which is a kind of fake sensor that can use whatever logic you'd care to stitch together. My "any PIR" sensor shows "detected" while any of the real PIRs is showing "detected" and withdraws that when none of the real PIRs is showing "detected". Second, I implemented what I call a "play dead" period, where the "any PIR" sensor will ignore things for a while after it has raised the "detected" signal. I have, in effect, implemented my own PIR sensor hold time, but now I am in complete control of it. The LED still reflects the "detected" signals of the individual PIR sensors.

Because of unmentionable problems with household members, the mains switch for the garage lights have been timer-controlled for several years. I replaced that switch with a smart WiFi switch. There are zillions of these on the market. The one I used was a Martin Jerry MJ-ST01. I chose this particular model because of positive forum comments about Martin Jerry from others, and because I liked its aesthetics. Our garage lighting uses a 3-way switch, and this smart switch can use a plain, old-school 3-way switch at the other location. It also gives me the option of someday upgrading the wiring to a 4-way switch arrangement.

Lucky for me, these switches came with "old" Tuya firmware that allowed me to do an OTA conversion to Tasmota firmware. Support for this kind of switch in Tasmota is solid and gives me very low latency local control.

My original plan for the project was to use dimming for all kinds of clever things. One hazy plan was to have the lights come on at partial brightness when automatically triggered but full brightness when turned with a switch. I also had ideas for a quick fade-up and fade-down to reduce the startle effect of the lights coming on and off. This change to a simple on/off switch means no dimming effects. For some reason, current smart dimmer switches can handle 400w of incandescent load but almost universally limit LED load to 150w. (I don't know the electrical reasoning for that difference.) The dimmable LED tubes I am using are 14w each. They are so bright that I only need 6 of them, which is only 84w. However, the fixtures have space for up to 12 tubes, which would be 168w. I don't want some future homeowner to unknowingly exceed the rated capacity of the switch. The simple on/off switches have an equally simple 15A rating.

With all of those things in place, I used Home Assistant automation to control the lights. There are a bajillion examples of this (sort of the "Hello world!" of smart home automation), so I won't bother with any implementation details. When the ESP8266 "any PIR" sensor triggers, the automation turns on the smart switch. The light stays on for 10 minutes after the "detection" signal goes away. 

One enhancement that I plan to make is to have the lights blink a couple of times before they go out for good. If someone is doing something without much movement, they'll have a chance to wave their arm or something before being plunged into darkness. That blinking was part of the grand design at the start of the original project, but it's now less interesting due to the sensitivity of the PIR sensors. It's hard to stay still enough to avoid triggering the PIR sensors.

• I am aware that I am now "settling" for an implementation that is somewhat similar to off-the-shelf possibilities that I was complaining about at the beginning of the project. Most of this just adds up to a simple motion-controlled light. A key difference (in terms of rationalizing things to myself) is that I was able to place the multiple PIR sensors in useful locations. A PIR sensor built into a light switch would not have helped since the light switch is not inside the garage.
• A future homeowner will not have the benefit of my home automation hub or even my WiFi network. The motion sensors will continue to trigger, but the ESP8266 will not be able to send its MQTT messages. The device will reboot once in a while to try to fix its network connection, but to no avail. The new homeowners will still have the WiFi smart switch. If I remember and am able, I'll convert them back to standard Tuya firmware so that they can still use the proprietary, cloud-based smarts.
• There's no display built into the control box now. If you want to know the time or the temperature or how long is left before the lights turn off, well, you have to figure it out some other way.
• I've accumulated a lot of various kinds of parts and components that were tentatively going to go into this project at some point, and now those never will. Oh, wait, that's a "pro", not a "con". Junk box, here we come.
• I may have to return the Nobel Prize in Light Switches that my son awarded to me a couple of years ago.

I didn't notice this until I was trying to place the headers for the I2C bus. I had intended to use the footprint for a 1x4 100 mil pitch male header strip. Without noticing, I selected a footprint that was 2.0 mm pitch. Although that is definitely a mistake, I can pretend it was intentional.

I routed the pins in the same relative order as the I2C bus signals are arranged in the Seeed Studio Grove system mentioned in an earlier project log. My plan was to use standard Dupont jumper wires to connect to off-board I2C components. By sheer luck, the Grove system uses the same 2.0 mm pitch JST connectors, and I have an assortment of connectors, cables, and hubs on-hand already from an unrelated exploration of Grove interconnects. The only difference is that my pin numbering is reversed from Grove numbering, but that just means turning the 1x4 connector around 180 degrees.

Although I wasn't planning to use Grove wiring for I2C, it actually makes things tidier than my original plan (which is the whole point of the Grove system and others like it). The resulting solution is:

• PCB mounted 1x4 2.0 mm pitch JST connector on the main PCB.
• Grove cable from the PCB connector to a 4-port "Grove hub" (a completely passive component that just breaks out the 4 signals across 4 identical connectors.
• From one of the hub ports, a hybrid Grove cable that has standard Dupont female connectors on the other end. I connected the individual connections from the Dupont end to the appropriate pins on the BME280 breakout board.

I can use this same arrangement to attach up to 2 more I2C components. (I might eventually attach a gesture sensor via I2C.)

If I ever do a V4 of this design, I will probably run all 4 signals to both a Grove connector and a standard 100 mil pitch connector so that things can be connected either way. I might also put additional connectors of one kind or the other (or both) to act as a (passive) hub on the main PCB.

This is some notes and pictures for how I finally decided to stack things together with the microprocessor board and the display board. (And the power supply board, but it's not really any kind of issue.)

Here is the microprocessor board in place with the header pins soldered on. As a reminder, and as you will see in some later pictures, the header pins are shorter than standard and are inserted into a 40-pin DIP socket that is soldered to the main PCB. You can also see that I left the battery connector intact, and the micro-USB right-angle connector is attached. (It is clear of the yellow connector on the right side, though the angle of the photo creates the illusion that they interfere).

The 17mm male pin headers turned out to be just right for mounting the display board. Here are some photos comparing them to the run-of-the-mill standard male pin headers.

The display board with the 17mm pins mounts with plenty of clearance over the microprocessor board, except that it just barely touches the battery connector. There is a sliver of vertical space between the display board and the micro-USB right-angle connector.

I'm not sure yet, but I guess I will probably remove the battery connector just to avoid future problems. It's easy to remove since it's a right-angle connector. I can just pry it up from the edge of the microprocessor board and either snip the two pins or fatigue them until they snap from bending the connector back and forth.

Here's the back side of the display board with the 17mm pins soldered in place. The display boards came with the 14-pin strip already soldered in place, so I had to remove that first. (If you don't have a good desoldering tool, removing a long header can be a pain. I have such a tool, so it wasn't too bad.)

The metal can at the top of the photo is the socket for the SD card. As a precaution, I covered it with (yellow) electrical tape, which you can see in the earlier photos. 

I have a few of these display boards, and I noticed that some of them come without the chip at location U2. That's the touchscreen controller chip. I don't know why some of the boards don't have it. I used a board that has it for this project even though I don't think I'll be able to use it due to how I plan to mount the circuit in a box. I just like to have options.

In hindsight, maybe I should have included some stand-off posts in the design, just for physical stability. The positions are shown on the main PCB silkscreen, but I didn't avoid them in the PCB layout.

My V3 PCBs arrived on Tuesday. Another quick turnaround from the PCB factory and DHL shipping. I wasn't quite as excited this time around since I was already expecting the quick delivery and I had only made small changes to the layout. Still, impressive.

Here's a view of the V3 board in the area of the microprocessor board:

I have placed the female headers for the display board and the socket for the microprocessor board. You have to look closely to see that the short male header pins are inserted into the socket.

I verified that the east-west spacing was exactly as expected (described in my earlier project log) by placing the microprocessor board onto those short pins. However, with the micro-USB right angle adapter plugged into the microprocessor board, it blocked the display board pins from going all the way into the 14-pin connector. Without the right-angle adapter, things are more or less OK. The battery connector on the microprocessor board does press on the bottom of the display board, and the microprocessor board header pins are dangerously close to the metal SD-card holder on the back of the display board. I'm not using the battery connector, and it can easily be removed. 

I haven't decided yet what I'm going to do about fitting things in the Z dimension. A couple of days ago, I ordered some 17mm male header pins just because I thought they might make things tidier, so that may take care of the whole problem. I'm hoping that I can leave the right-angle adapter in place and might be able to leave the battery connector intact, but I can sacrifice both if necessary. Since the microprocessor board is socketed, I can simply remove it if I need to do a firmware update over USB. (With this new V3 spacing, some normal micro-USB cables can be snugly inserted if the display board is removed.)

When I did V2 of the PCB, I wanted to leave more room between the USB connector on the microprocessor board and the tall female headers for the display board. I did that. What I didn't do was pay attention to the other end, the 4-pin female headers for the display board. I faked myself out by relying on the silkscreen image of the Sparkfun ESP32 Thing board. (Which I myself created, so that's my fault, too.) On the silkscreen, it looks like there is plenty of room. On the actual V2 board, that end of the microprocessor board protrudes a few millimeters too far and pushed on the 4-pin header.

I thought I had a good workaround for that. That end of the microprocessor board is fairly empty. It just has a small sliver of empty PCB and then the PCB antenna for wifi. I thought I could carefully shave down that end with a file or some sandpaper. In fact, I still think I can, but it's a tedious and error-prone process. Here's an image generated from Sparkfun's published ".brd" file so you can see what I'm talking about.

(BTW, that graphic was rendered by Altium's free online viewer (https://www.altium.com/viewer/), which I found to be quite nice.)

After I filed and sanded quite a bit (on a microprocessor board that I had kind of wrecked through earlier foolishness), I was starting to get into the PCB antenna, and it was still pushing on the 4-pin header. I decided that I was becoming part of the brute squad, so I went back to my PCB layout and moved the microprocessor board exactly 100 mils (2.54 mm) "to the east" away from the 4-pin header. The advantage of moving exactly 100 mils is that I could check the spacing on the V2 PCB by just moving the microprocessor board by one pin on the header pins I had placed to check the spacing.

By incredible good luck, it turns out that the microprocessor board with a micro-USB right-angle adapter exactly fits in the space between the two sets of headers for the display board. I don't mean "it sort of fits". I mean, it fits like it was made that way. I'm glad I didn't try to plan it that way, or it would surely have not worked out. 

Here's a picture with a microprocessor board that was not filed/sanded at all.

In the upverter.com PCB layout tool, it was easy to move the microprocessor board by 100 mils. I merely had to select the part, hit the "inspect" button, and add 100 to the x coordinate. Re-routing the traces was much more tedious. There might be an easier way to do it, but a lot of things in Upverter aren't completely intuitive to me. It was easy to move vias by the same technique of adding 100 to their x coordinates. For the traces, the only metadata given to me was the trace width and total length. Perhaps I could have done something by exporting to Upverter's "universal" (*cough*) JSON format, editing it, and re-importing it. Instead, I just laboriously moved the traces individually. Man, there sure are a lot of connections coming out of the microprocessor board.

The V3 boards (https://upverter.com/design/wjcarpenter/oelscv3/) are currently being created at jlcpcb.com.

Wow. Wow, wow, wow. I clicked "pay now" on a Monday evening. The following Monday, in the afternoon, I had the boards in my hands; a few hours short of a week and less than $20.

When I decided to have new PCBs made, I was prepared for a big delay, especially during these pandemic times. Ordering parts from China is hit or miss on shipping delays. I guess that's because a lot of small package shipping is done as cargo on passenger flights. With fewer passenger flights, competition for space is tough. There are also all kinds of you-never-heard-of-them shipping companies being used, with whatever arrangements they can figure out. I chose DHL for shipping, and the estimated time was 2-3 days. I didn't really know whether to trust that estimate, but it was true. I guess DHL probably operates their own all-cargo flights from Asia to the US, so their capacity is not diminished by there being fewer passenger flights.

I ordered these PCBs from https://jlcpcb.com/ with the usual process of uploading a ZIP of Gerber files. The forms for ordering PCBs from many of these China-based PCB factories look very similar, so I imagine many of them are just taking orders for someone who actually has a factory. JLC has enough info on their web site that they either have the factories or they do a very convincing job of talking about them. :-) 

Here are pictures of the new boards with the original boards for comparison. You can see that the V2 boards are much less cramped. I was going to have the V2 boards made in a different color. It was the same price, but was said to have up to 2 days production delay, so I went with the default green.

One of the possible mistakes I made in the first iteration of the PCB was in not thinking very precisely about the current capacity of the traces the carry power to the lights. I just laid out the PCB without calculating that. With the larger board area in the V2 PCB, I had room to make those power traces bigger. I wasn't sure how big to make them, so I just SWAGed it at 100 mils.

Today, I finally got around to figuring out what I should have done earlier. It's easy to find PCB trace width calculators on the web. I used this one https://www.4pcb.com/trace-width-calculator.html, but there are many others. My earlier measurements were a max of 20w of current draw, less than 1.5A at 12vdc. The PCB is less than 4 inches wide, but allowing for circuitous routing, I used 5 inches.

The calculator tells me I need a trace width of 21 mils for the top or bottom layer. I guess 100 mils should cover it! Even the 50 mil traces that I had blindly used on the V1 PCB now look good enough.

The pins that are connected to the GND copper pour were drawn with wagon wheel connections, which is intended to make soldering easier. I was a little skeptical of the current-carrying capacity of those spokes, so I smudged over some of the gaps with the trace drawing tool to give a thicker connection. Maybe I didn't need to do that, but maybe I'm not an actual EE.

I decided to create another revision of the PCB to correct the various mistakes in the first round. 

The original board dimension was about 94mm x 65mm. I did the layout as compactly as reasonably possible since I planned to house the circuit in a standard US electrical box. That compactness led directly to some of the problems I later encountered. I now know that the box I will use is 110mm x 190mm (minus some corner cut-outs). Since the inexpensive PCB fab houses typically have special pricing for prototype runs of 100mm x 100mm or smaller, I opted to spread things out and use the complete 100mm x 100mm for the layout.

The new board layout is in the project: https://upverter.com/design/wjcarpenter/oelscv2/. The schema also has minor updates.

Besides the more relaxed layout, the revised design has:

• pins for the I2C bus so I don't have to tack onto pins of the microprocessor board
• pins for the single previously-unused microprocessor pin, possibly to be used for an audio alert buzzer
• corrected wiring for the MOSFETs
• external pull-up resistors for the pins that need them (easier than rearranging the pin assignments)
• current-limiting resistors for the PWM signals to the MOSFETs
• replaced the 2-pin screw terminals with euroblock connectors
• top-layer copper pour for +3v3 (in addition to existing bottom-layer GND pour)
• wider traces for the +12v and return paths

Today, I found another blunder of mine. This one is a whopper in the part of the circuit around the MOSFETs.

I had originally tested the MOSFETs I'm using on a breadboard. They worked as expected with PWM output from an ESP8266. That was a long time ago, and I've switched to using an ESP32. I've also tested the PWM pins I'm using with a simple LED circuit. Again, it works as expected. When I finally got around to testing the MOSFET outputs on the assembled board, I got only a very weak and erratic output.

It turns out that I had not tied the MOSFET source to ground. (These are N-type MOSFETs, to the terminology is counter-intuitive for me; source is ground, and drain is positive [or at least "the other one"].) It's not that I tied it to the wrong thing ... it's that I hadn't tied it to anything except the load. I guess I must have been thinking that it was fine for the load to fill up with electrons forever. Actually, I don't know what I was thinking, but I hope any EEs can get a chuckle out of it.

This was fairly easy to solve since I just needed to jump the source pin to ground. It's not a mere signal, though. It's got to carry to current for the load. So, I tied each source pin to a ground pin from an input power supply. Unfortunately, those are completely across the board from the MOSFETs. Notice the professional looking black wires in this photo:

The bad news is that the board now bootloops. I confirmed it's the jumpers causing it by cutting them. I'm not sure what is causing the problem. My current suspicion is that the MOSFET gate is drawing too much current for the GPIO of the ESP32. (12mA might be a safe max per GPIO https://esp32.com/viewtopic.php?f=2&t=2027) If that does turn out to be the case, I can add a current-limiting resistor. I should be able to do that with the current PCB by brutalizing the gate leg of the MOSFET. Because it's surgery, I won't do that until I'm more confident that that's what the problem is.

...the next day...

OK, I think I have this figured out. It's a couple of related blunders with the same root cause, which is incorrect wiring for the MOSFET. It's crazy, but I just couldn't see the problem clearly in the entire schematic. When I drew the MOSFET part of the circuit in isolation, it became much clearer.

In isolation, here is the circuit as originally designed. It's bad because the electrons check in, but they don't check out.

My first attempted fix (described above) was foolhardy and actually made things worse. In addition to providing a way for the load to connect to ground, I actually provided a way for the +12v supply to connect to ground when the gate turns the MOSFET on. It was like fixing a traffic jam by driving all of the cars off a bridge. When the MOSFET is off, the load would be on (the opposite of what I want). Since my current firmware had the gate on at 50% duty cycle, I was shorting the power supply to ground half the time. And that is undoubtedly why I got a boot loop. There was no power left to feed the rest of the circuit on the PCB. D'oh!

Here's a picture of the cure-worse-than-the-disease:

Finally, here is what I think the circuit actually should be. Turning the gate on provides a path to ground for the load. With the gate off, there is no path to ground (for anybody!).

I haven't actually wired things up this "good!" way yet. But it looks right, and I've never been wrong before. 

Rewiring means moving the drain leg (pin 2) of the MOSFET to connect to the land currently occupied by the source leg (pin 3). Moving the drain leg will also break the connection from drain to +12v (but it will still go to the load through the now-empty land). The source leg will have to dangle in the air and be jumpered to ground. I'm still trying to decide whether I need to bother with the current-limiting resistor for the gate leg (pin 1). I'll probably will, but I'll make a game-time decision when I'm back at the soldering iron. Whatever I do, the MOSFET mounting will turn from something tidy to something gross-looking.

I've revised the layout of what shows up on the display screen. I'm still tinkering with it. Besides fiddling with color combinations, I'm trying to decide what's best for someone either working in the garage or just walking past the controller. Here's a nice picture. The screen is slightly cloudy because it still has the protective film on it.

• In the top left and right corners are sensor readings (green) from the BME280 (except for the word "garag", which is the device's esphome node name (blue)). It's relative humidity, temperature in both C and F, and air pressure (I guess it's actually station pressure) in both hectopascals and inches of mercury.
• The yellow "6:37" in the top center is a countdown timer. It's the minutes and seconds until the lights will turn themselves off in the absence of motion detection or the use of any of the controls. When it gets down to 30 seconds, it changes to red and starts blinking. If there is any activity, the count resets and starts counting down again.
• The large white "18:14" in the center is a time-of-day clock with hours and minutes. The ":" blinks, and I happened to take this photo when it was blinked off.
• The section along the bottom gives the state of the dimmer control. It uses a graphical thermometer control (red on green) as well as a text overlay (cyan).