Unstable Behaviour of the light strip

[DirkTas67]

Hello,

I recently made the light strip, I took the code here from github and compiled it for the Nodemcu v1.0.
Made the changes in Home Assistant and everything 'works'.

I only have one problem, I can switch on the light strip, choose an animation then after an amount of time the light strip goes out, when switching it on again it is white (not the previous animation).

The time between choosing the animation and switching off changes, it can be 30 seconds, it can be 15 minutes.

when compiling with arduino IDE 1.8.5 i see errors
pragma message "FastLED version 3.001.006"
pragma message "No hardware SPI pins defined. All SPI access will default to bitbanged output"

My light strip is a WS2812B (thats what I think, at least the website where I bought the strip tells me ;-) )
so I put the WS2812B where WS2811 was

any idea's

Dirk

[debsahu]

Add #define FASTLED_INTERNAL before #include <FastLED.h>

[DirkTas67]

This will hide the error/message but probably won't solve the problem right?

[debsahu]

Your WiFi connection might be slow. I use a separate router & domain just for iot stuff. Also check how fast your mqtt server is, is that getting bogged down by barrage of data? Subscribe to the topics set in your code on a separate mqtt client (you could use mqttfx) and see if you are receiving mqtt messages instantly?

[DirkTas67]

I think I ruled out a power problem, when selecting a solid color then the light strip can run for hours, nothing happens, I choose white on full brightness. The hardware is pretty simple, I choose for the 5V version of the WS2812b (checked the difference between 2812 and 2812b and I seem to have a 2812b, ws2812 have 6 connections, ws2812b have 4), I choose to not use the level shifter since I only use 106 LED, the NodeMCU is powered directly from the 10A 5V powersupply , the GND and +5V are also connected to the LED strip, D5 of the NodeMCU is connected to the datapin of the LED strip.

There is also something else I noticed, when selecting an animation and let it run for a few minutes, then switching off the led strip in HASS.IO (before it crashes, the nodemcu is still connected to the power), it remembers my choice when switching it back on, even if the period between switching off and on is like 24 hours, so that means that the nodemcu did not crash in between.

Wifi is probably not a problem, I have an Ubiquiti AC Pro and AC LR, both can handle lots of connections (250+)

the MQTT server is Mosquitto and is 'part' of the Hass.io instalation on a Raspberry Pi 3.

[debsahu]

1. Hardware: Its nice that you ruled out power supply problems. I recommend to have a 1000uF cap on the power supply line just before the strip and a 500 Ohm resistor between D5 and data pin to save your first LED from a burn out. I personally use 3.3V to 5V level shifter for 120 WS2812B strip.

2. Arduino IDE: Instability of NodeMCU is because of the same processor also does try to maintain WiFi connection and run your code. In Arduino IDE, File -> Preferences. Change the ESP8266 board manager URL to latest prerelease https://github.com/esp8266/Arduino/releases/download/2.4.0-rc2/package_esp8266com_index.json and update your board on Arduino IDE (Tools -> Board -> Board Manager -> Update) to 2.4.0-rc2. I assure you this will help a lot with ESP8266's stability.

I also have these lines before #include <FastLED.h>

#define FASTLED_INTERRUPT_RETRY_COUNT 0
#define FASTLED_ALLOW_INTERRUPTS 0
#define FASTLED_ESP8266_NODEMCU_PIN_ORDER
#define INTERRUPT_THRESHOLD 1
#define FASTLED_INTERNAL

In order to get quicker boot up (<1s) I set the AP mode and manual IP before WiFi.begin(ssid, password);,

IPAddress ip(192, 168, 1, xx);     // where xx is the desired IP Address
IPAddress gateway(192, 168, 1, 1); // set gateway to match your network
Serial.print(F("Setting static ip to : "));
Serial.println(ip);
IPAddress subnet(255, 255, 255, 0); // set subnet mask to match your network

WiFi.config(ip, gateway, subnet);
WiFi.mode(WIFI_STA);
WiFi.setSleepMode(WIFI_NONE_SLEEP);

This last step would consume more power because it keeps the WiFi active all the time. Also since it does not require AP mode, fixing this to STA mode also helps with the stability.

3. Mosquitto: I personally use mosquitto and love it, but could you also check using MQTTfx client and see if you receiving messages instantly on your mosquitto server? Also if you have the retain flag to true, your mosquitto server will save your last message. So every time any client connects, it gets that message as the latest message. This could explain your memory effect you are mentioning in your last part of previous message.

[DirkTas67]

Changed the code and the board manager (forgot to mention but I allready had version 2.4.0-rc1 of the board manager) and uploaded it again to the NodeMCU, it ran 3 hours and 49 minutes with a solid color but after 5 minutes having an animation it stopped.

Installed MQTT Snooper on an Android tablet and every animation you select shows up as a JSON message immediatly on the snooper, so no problems there.

Next option is the Level shifter, I assume that I don't have to use the 500Ohm resistor then, will use the 1000uF capacitor when I change things. Let's hope it fixes the problem.

[debsahu]

Could you try one more thing, connect a computer to the USB of NodeMCU with serial connection and see if it spits out messages it receives on the serial monitor over time?

[debsahu]

Also look at NeopixelBus by makuna. One can rewrite all of this into neopixelbus format. I havent done it, but from my experience this is just a great approach. This thread sums everything up: Makuna/NeoPixelBus#184 The NeopixelBus uses RX pin and is independent of CPU instructions.

[DirkTas67]

Checked with the USB connection, no output and when the NodeMCU resets it changed the serial port from USBtty0 to USBtty1 and I'm not fast enough to see if there's any output ;-)

I will add the level shifter and capacitor on saturday and see if that helps, if not I can check another project like (McLighting and see if that works.

[DirkTas67]

Talking like Ben -> Added Capacitor and Level shifter,does it work, NOPE :-)

So I decided to go another path, I used Platformio to build and installed the same code, and guess what, animation is running 35 minutes now, let's see if it keeps running.

[encor50]

@DirkTas67 how do you use Platformio to upload this code i cant find the right way :P

[DirkTas67]

The SAGA continues,

The animation didn't keep running, so I decided to do it again, a new NodeMCU, new Capacitor, new Level Shifter, new wires, the only thing I had to keep was the power supply.
Connected the thing, and BAM .... 30 seconds later the lights died again :-(
So no it wasn't the hardware, I had installed MQTT Snooper in a previous step and when the lights go out, I can acitvate them immediatly again with publishing the JSON MQTT message (it's as simple as tapping the message if you have send it previously) so micro seconds later the light were on again, so a reset of the NodeMCU was impossible.

Next step I am trying right now is log in into the rapsberry pi and stopping hass.io
-> hassio homeassistant stop

Lights are now running for 1 hour.

So maybe Home Assistant is the culprit (I'll wait several hours and start home assistant again), anybody had this kind of problem before?

[DirkTas67]

@encor50

What do you want to know?
I am using Platformio in ubuntu so I have no idea if I can help you.

[DirkTas67]

Ok I think it works ;-)

Instead of the resin HASSIO 1.1 image I installed the hassbian image.
Now the light strip is stable allready for over 2 hours, I tested the light strip yesterday afternoon by starting it and then stopping home asssistant, it kept running until I stopped it more then 5 hours later.

[ThAnKm3Lat3R]

@DirkTas67 any chance you could post a download link for the hassbian image? I am having this same problem as well.

[debsahu]

You can find the latest Hassbian here: https://home-assistant.io/docs/installation/hassbian/installation/

[Makuna]

Please search the FastLED issues; on the esp8266 the library has issues as it doesn't use hardware to drive the LEDs and with the use of WiFi you can't reliably update the pixels. There is a great writeup in one issue that shows the up time comparisons to all the libraries for esp8266.

[ddykhoff]

The issue @Makuna is referencing is here: FastLED/FastLED#306

The last comment in that thread is a fork of FastLED which allows you to write to the LED pixels in a different way which avoids the WiFi interference issue (or so it seems, it at least avoids the WDT resets).

To fix the behavior seen here, download the fork https://github.com/coryking/FastLED to a zip file named FastLED.zip and import to your Arduino IDE. Then in your controller code add the line #define FASTLED_ESP8266_DMA to the top of your code, as well as changing the pin to 3 (and adjust the wiring on your chip to use the RX pin). You should also remove any interrupt bypassing (#define FASTLED_ALLOW_INTERRUPTS 0).

This has fixed the stability issues for me. Now to figure out why my 5m wire run causes flakiness on the pixels on the far side of the run 🤔

[lance36]

thanks @ddykhoff, im having the same issue and i'm gonna try that fork.

for the issue you are experiencing, try using a multimeter at the far end of the strip between 12v and GND, what are you getting?

[lance36]

Animation speed is all over the place with that fork using a 6 pixel strip... gonna try and figure out why :D
Edit:
using the DMA method seems to be much cleaner, board seems stable now.

too bad all the animations @bruhautomation wrote use some sort of delay that with the new method seems much faster

[lance36]

This has fixed the stability issues for me. Now to figure out why my 5m wire run causes flakiness on the pixels on the far side of the run 🤔

@ddykhoff what strip are you using? WS2812B? WS2811?

[ddykhoff]

@lance36 Yes, they are WS2811's. I thought I had measured the voltage before but I just did again and it's ~8V at the end of my strip and ~10V where the issue starts occurring. Looks like that is the source of my issues. I'm going to test it over the weekend.

Initially I was suspecting the necessity of a null pixel, but that seemed odd to me because the data sheet for WS2811 states any pixel to pixel wire runs <10m should be alright. This makes much more sense.

[lance36]

at how much AMP is your power supply rated at?

turns out i was using D3 pin with DMA and not RX

[ddykhoff]

@lance36 Yeah I updated my comment to state to use the RX pin, I made the same mistake as well.

I made a post here with more details on the issue I am facing. Supplying voltage to both ends of the LED strip didn't solve my problem. The power supply I am using is 12V 5A.

[lance36]

Hey i just wanted to add, using DMA mode dosen't seem to require a logic shifter either.

i'm controlling a 5m (300 led\100 pixel) directly from the nodemcu RX pin.

the only effect that seems to flicker a bit is the candy cane, will investigate further. maybe.

[ddykhoff]

@lance36 Are you saying that the RX (GPIO pin 3) outputs 5V? Because my understanding was that all the GPIO pins output 3.3V, in which case a logic level shifter should ideally still be used, especially on longer runs.

[lance36]

No, what i'm saying is that i was able to consistently pilot a 5m WS2811 strip without a logic shifter and directly from the RX pin (which should output 3v3) using the DMA mode, while previously i would experience flickering and instability.

[DirkTas67]

Hello,

Inserted the first line #define FASTLED_ESP8266_DMA and removed #define FASTLED_ALLOW_INTERRUPTS 0 and several other lines with the word 'INTERUPT' in (not originaly in Ben's code but added by someone else here (somewhere).
Got the FastLED fork from https://github.com/coryking/FastLED and inserted it in Arduido IDE.
De-soldered the dataline from pin D5 and soldered it to D3 and flashed the firmware.
The LED animation did run from 8 this morning to 7 this evening so it is certainly more stable but I noticed some flashing of the LED's (flashing that is not part of the animation).

Now I read that I had to solder the dataline to the RX pin of the Nodemcu, what is the difference?
#define DATA_PIN 3
This line have to be changed then, is the RX pin called RX in the code?

Regards,
Dirk

[lance36]

This line have to be changed then, is the RX pin called RX in the code?

Check the pinout:

GPIO3 and RX are the same pin, that is what you should be using with the DMA method.

[DirkTas67]

@lance36 thank you for you answer.

I know where the RX pin is on the Nodemcu, my question was how I have to define the RX pin in the code, my best guess is the pin is D9, i will know when I flash again, for now the datapin is connected to D3 (GPIO0) and defined as '3' in the code and it works OK

[lance36]

For dma i noticed that it dosent really matter what Pin you define, it will output on RX in any case. Il 21 gen 2018 15:34, "DirkTas67" <[email protected]> ha scritto:

…

@lance36 <https://github.com/lance36> thank you for you answer. I know where the RX pin is on the Nodemcu, my question was how I have to define the RX pin in the code, my best guess is the pin is D9, i will know when I flash again, for now the datapin is connected to D3 (GPIO0) and defined as '3' in the code and it works OK [image: nodemcu_pinout] <https://user-images.githubusercontent.com/30079864/35195198-4faac0c4-fec0-11e7-98f7-07459de4896a.jpeg> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADF-9PXlPzLULPkzKPS7RuQOh6L8Lqatks5tM0rrgaJpZM4Qez5T> .

[TheCellMC]

Hey @debsahu! I have 120 WS2811 led's. What resistor and capacitor would you recommend me to get?

[debsahu]

@TheCellMC As per https://learn.adafruit.com/adafruit-neopixel-uberguide/best-practices , use any value between 300-500 ohms. It is used to protect the first LED on your strip from burning.

[Rudertier]

Hey,
does anybody know if the "FASTLED_ESP8266_DMA" method also works if I need a clock signal? I have the feeling it does not.
Best

[debsahu]

Check out my adaptation of McLighting using MQTT Light. Does not stop all of a sudden (FastLED + esp8266 issues), I have this on since yesterday and it had been chugging along fairly well. https://github.com/debsahu/McLighting

[lance36]

@debsahu does all the animation work? care to share a video?

[debsahu]

@lance36 everything works. Video is incoming soon (this weekend).

[lance36]

Tried your code, couldn't get a status or give commands from HA.
rolling back for now, will test more tomorrow.

[lance36]

i finally found time to test it again. got it working but i'm still experiencing horrible flickering, i think there may be some interference with the wirings at this point...

not using a level shifter, 95 led on pin 3.

[debsahu]

Try McLighting, I created a fork https://github.com/debsahu/McLighting

[lance36]

Yeah, thats what i was talking about :)

turns out its probably a faulty cable on my gpio.

BTW, check my pull request because your code wasn't compiling

[encor50]

#92

[proxycase]

I know I'm months after the fact but resistor on the data pin absolutely helped. Thought the capacitor was the only thing I needed, but it would get glitchy with me every now and then. Just leaving this comment just in case someone else finds it. 500 ohm resistor on the data line connected to 3~ on the arduino (an UNO in my case) and 1000uF capacitor on the power line.