Testing Out RGB Manual Control

I’ve been thinking about how to control the hamstercage light project, and what is really needed. My first idea was to see if I could control the project via WiFi, perhaps by using an app (via Blynk, likely). However, seeing as Blynk uses a freemium model, I felt reticent to go ahead with it. After all, what if Blynk changes its terms of service? What if what I need takes a monthly payment? What if adding a second user isn’t possible? I don’t like trading ownership for convenience, so I’ve decided to abandon that idea. That did mean I had to thoroughly consider alternative controls.

As I’d considered before, I quickly settled on manual controls. After all, the idea is to automate the hamstercage lights nearly all of the time, with exceptions for when we want to see more clearly into the cage (for cleaning, or finding the hamster). Clearly, we’d be next to the hamstercage when we’d want to have direct control of the lights, ergo having manual controls makes the most sense. Doing a quick read online made me conclude that the usual means of controlling RGB leds manually is using potentiometers. Fortunately, I had a few ones lying around, so I quickly wired something up to test:

Figure 1: The breadboard test of controlling RGB lights with potentiometers

I’m breaking a bit with my usual color conventions here, as I’m using black as ground and orange as 3.3V. The WS2812B take 5V but I figured this would work well for the time being. You may notice that I also don’t have a resistor between the powerline and the WS2812B LEDs right now; that’s firstly because the setup wasn’t working when I started, so I reduced components to see when it would work, and secondly because the 3.3V certainly wouldn’t exceed it’s Vmax of 5.5V in any case.

The ESP32 has a really nice number of ADC pins (which I’ve learned stands for Analogue to Digital Convertor), so I had a bevy of choice to connect the potentiometer to. Essentially, the ESP32 compares the voltage from the middle pin of a potentiometer to 3.3V, and then outputs a value between 0 (for 0V) and 4095 (for 3.3V). Since the WS2812B takes a value between o and 255, it’s a simple case of dividing the value from the ADC pin by 4096/256=16 (The off-by-one programming mistake isn’t catching me here!). That gives me three 8-bit values to put into the RGB LED.

After some uploading problems (I had not connected the ground pin, which apparently was a problem for uploading to the chip), I had a working prototype. This setup managed to control the color decently, though I didn’t seem to get as much color variation as the FastLED library demo gave me. Moreover, the results were a little inconsistent. The cause of both issues would be the potentiometers. Firstly, the values aren’t precise, which of course the FastLED library demo does have, seeing as the values are specified in code rather than by analogue input devices. So, when I’m turning a potentiometer, the numbers go up in rather large jumps. One challenge to overcome, then, is to get a better resolution (for lack of a better word). The second problem I ran in to was that the color seemed to flicker a little, which again I attribute to the potentiometers. The potentiometers I’m using are not quite a comfortable fit in the breadboard, and I suspect that the connection they make is shoddy. I noticed that there was quite some wobble to them, and if I’d touch them, the hue would change.

All in all, then, I’d call this quite a succesful test. I have a proof of concept, in that I know I can control the colors of the LED strip using potentiometers. The follow-up is to get better control. The next test I want to do, however, is to work on the WiFi-side of things, and test out getting the current time from an NTP server. Once I’ve tested that, I’ve established all the ground principles I need to create the hamstercage light project, and I know I can start working on refining all the individual elements of it.