I've just finished writing an instruction sheet, for my IoT students, on how to control NeoPixel strips.
Note: This exercise uses a WeMos D1 Mini, Node-RED and MQTT (mosquitto) and of course a NeoPixel strip.
I hope you enjoy reading this as much as I enjoyed writing it.
Regards from David.
PS: The document, in the above link, has been updated to implement the comments from various people.
Looks good. I think the only thing I would have added would be some commentary about how much power the neopixels take and what happens if you put too long a set directly onto the D1-mini such that you draw too much current through it.
The lines:
You may find you can connect the D6 pin (GPIO-12 data output) directly to the Data-In pin of the NeoPixel strip (and dispense with the level shifter).
bother me because I can see a kid saying "oh I'll just connect it to D6" but what might happen? Could it work in some cases and blow the D1 in other cases?
In the task settings you have this:
...so make sure ‘Strip Type’ is set to RGB.
I was going to mention the current but @TotallyInformation beat me to it 
What type of neopixels are you using?
Thanks guys for all your valid and useful comments - I'll expand the text to cover current consumption.
I'm only using a NeoPixel strip with just 8 lights so current consumption is not too high. The strip is powered from 5V which comes before the on-board regulator on the WeMos D1 Mini board (so I assume it connects directly to the power supply that is being used to power the WeMos).
Well spotted Paul. The naming is confusing - I think I'll take it up with the ESP Easy people as I think it should read "RGB" as the syntax for the NeoPixel command is red,green,blue.
Great. I always think that powering LED's is a good intro to power/current/voltage discussions and always useful to know.
You are correct of course. You just need to make sure that your external power supply has the capability to power both the Mini and the LED's.
I think that the D1 mini can consume up to about 500mA. Then each pixel of your neopixel is, I think, about 60mA. So you need a power supply capable of delivering 1amp or more.
I think that the most useful and practical thing I ever learned from school electronics and electrics (physics) was about "Ivy Watts" - I x V = W. Once you remember that, it is so much easier to remember not to burn the house down with inappropriate wiring! 
Depending on your wemos board, then I think there may be a diode between the 5v on the USB and the 5v pin. So it depends if you are using the USB to power it all.
Hi Paul,
Re: Your comment about the D6 output on the WeMos D1 Mini.
D6 is being used as signal line to the first NeoPixel in the strip. The way NeoPixels work is that they are daisy-chained together, so each one sends a signal containing information to the next one.
This means the D6 output only has to supply input current to the first NeoPixel. I'll check the "specs" later but I suspect the input current will be very low and well within the drive capability of an ESP8266.
re D6 - it's more to do with levels than current. driving a 5V circuit from a 3.3V output will be safe (as 3.3 is lower than 5) - the only issue is if the actual On level is sufficient to register as a 1 on the 5V side... I must say that in my experience that has always been the case as usually anything above about 2.1V is a 1 (on the 5V side - and below 0.7 V is a 0) is ok - so it is likely to work.... but not guaranteed. YMMV etc.
Nice, thanks for sharing. I have not considered level shifters in the past. I have a 32x8 matrix display connected to D9 in my case and it works a treat. No issues controlling all these pixels at all.
But for a new project, I got individual neopixels each on a small PCB. I have daisy chained 4 pixels and put together a very simple sketch to rotate some colors. The first 3 pixels are OK, the 4th pixel is displaying random colors at random times. Is it possible that my soldering and wiring is creating so much resistance that signal does not get to the 4th pixel? Unfortunately I don't have a scope to check signal levels on the pixels.
Hi Dave,
Yes I agree with the voltage level being more important - I was just answering Paul's question as I think he was concerned about the current load with so many NeoPixels.
In my experience interfacing 3V3 logic to 5V has worked fine, as the 3V3 logic-high is above the threshold for the 5V input pin.
The main problem, as I tried to highlight in the article about Ultrasonic Distance Sensors, is interfacing 5V logic to 3V3 logic when do you need a level shifter.,
Hi Csongor,
I've not tried joining NeoPixel strips together.
I purchased three strips last month and so far have only used them singularly.
As soon as I have some spare time (ha, ha, ha) I'll give it a go - and report back.
I have individual pixels on separate PCB like this on Adafriut, but from a cheaper source from China: https://www.adafruit.com/product/1612
Regardless it should all be the same. Of course the 4th pixel may be faulty.
Let me use this thread to ask another question: I am using the Adafruit Neopixel library. I noticed that as I turn the brightness down (setBrightness function), my colors start to bleed a bit. Yellows turn to orangish, orange to redish and darker shades of grey to black. This has nothing to do with driving the signal from 3.3V, most probably the color calculation in the library, right?
Hi Csongor,
Sorry - I'm not using the Adafruit Neopixel library, so can't really help.
I'm using ESP-Easy with their device driver to control NeoPixels.
This interacts at a very basic level.
The structure of the command is position,red_brightness,green_brightness,blue_brightness.
If you have a level shifter laying around, definitely try using one. 3.3V will cause issues when you least expect it. Prototyping will go smoothly, but the minute you start packaging your solution for a production context you'll realize that 3$ could have saved you a lot of trouble
Source: Best Practices | Adafruit NeoPixel Überguide | Adafruit Learning System
I've had no issue using those two:
Cheers
Thanks a lot. Let me go through this.
I thought the fact that each led had a Din and Dout pin means that the Dout must be re-driven as the signal passes through, so would be level shifted by the first diode in the string. So if one worked they should all work. Of course that doesn’t fix overall supply current requirements or any timing issues
Hi,
I read this in the ESP Easy forum about just one NeoPixel light coming on at random times.
// Solved !
// I used the same pin for wifi status led and Neopixel output !
He had used GPIO-2 to drive a NeoPixel clock (as well as indicating WiFi status).
Oops - sorry this reply was meant for @nygma2004
Those strips go bad all the time and that's the behavior we see: One pixel will flash randomly or remain only one color, and all the ones after it will be messed up. The fix is to cut the bad pixel out of the strip, then solder the strip back together. (I usually put it together with alligator clips before soldering to make sure that was the only bad pixel.)
They're just fragile. Lots of bending lifts the components from the strip. We've stored strips on spools in a shipping container in the desert for a year (because Burning Man) and when we tested them the following year all of them had gone bad. We had other strips stored flat, and those all were fine. So my assumption is the thermal cycling combined with the curve of the strips caused pixels to lose connections to the strips. And in general, if you're bending a strip a lot you can expect a pixel to fail every now and then.
The strips I've been using are 5.5cms long and rigid.
If you tried to bend them, then I'm sure they would break in two!!
It sounds like your 'strips' are supposed to be flexible.
I've no experience with this sort of strip.
Cheers from David.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
