Flickering on ESP8266 3.1.2 and 3.1.1 #1599

Souravgoswami · 2024-02-14T17:36:56Z

I'm currently working with this repository:

https://github.com/Souravgoswami/Arduino-FastLED-Cool-Effects

You can find the ino file at this location:

https://github.com/Souravgoswami/Arduino-FastLED-Cool-Effects/blob/master/Arduino-FastLED-Cool-Effects.ino

I acknowledge that the code might not be the most readable, but the main issue I'm facing is random flickering on the WS2811 chains when used with a D1 mini. I've tried different D1 minis and WS2811 chains, but the problem persists, leading me to suspect the low 3.3 logic level, which previously worked without any issues.

To address this, I used the TXS0108E IC to shift the signal level and observed that it performed well when viewed on a scope:

But the same the flickering issue remained unresolved, even with a relatively short signal wire.

Currently, I'm using the HEF4050BP, which does distort the signal slightly, but I don't believe this to be a significant problem:

Here's an image with a single sweep:

Then I did something stupid, I added a Serial.begin(115200) to the setup() function (without any print statements), now the flickering disappeared!

I then removed the Serial.begin and added a counter to my code to increment the design by 1, which also worked perfectly. This leads me to suspect an issue with the compiler.

By default, I compile with the Os optimization level. However, when I tried O2, the flickering intensified.

The flickering disappears with O1, O3, and Ofast levels, suggesting a potential software issue.

Here's the flickering with Os using ESP8266's 3.1.2:

flickering-Os.mp4

And here's the flickering with O2 using the same ESP8266's 3.1.2:

flickering-O2.mp4

The flickering issue persists regardless of the colour of the light. At the Os optimization level, the flickering is greenish hue, and at the O2 level, it appears bluish. Consequently, when I illuminate any colour other than green at the Os level, the flickering becomes noticeable. The same is true at the O2 level when I illuminate any colour other than blue, the flickering becomes visible.

Upon inspecting my software, I didn't find anything particularly suspicious.

I then downgraded to ESP8266's 3.1.0 version from 3.1.2 and found that the flickering disappeared even at Os or O2 levels.

After installing the 3.1.1 library, the flickering returned.

I'm using Archlinux's avr-gcc 13.2.0-2, avr-binutils 2.41-1, avr-libc 2.1.0-3, avrdude 1:7.3-1.

Does anyone have any insights into what might be happening?

I'm unsure whether to report this bug here or to the ESP8266 team, but I'm assuming it's a FastLED bug that doesn't work reliably with 3.1.1+ versions of ESP8266?

At the moment, I believe that deciphering such extensive assembly could be quite challenging for me.

The text was updated successfully, but these errors were encountered:

Souravgoswami · 2024-02-14T21:28:39Z

Ah, this glitch is because of:

#ifdef BOARD_ESP8266
  #define FASTLED_ALL_PINS_HARDWARE_SPI
#endif

Removing that fixed it! This directive instructs the FastLED library to use hardware SPI for LED communication. But WS2811 LEDs require precise timing control that doesn't probably align with standard SPI communication.

By removing this, we revert to software bit-banging, which accurately generates the necessary timing for WS2811 LEDs, eliminating the flickering issue.

The compiler message:

157 | # pragma message "No hardware SPI pins defined. All SPI access will default to bitbanged output"

can be confusing, as noted in the discussion here: #1169 (comment)

For LED strips like the WS2811, which rely on precise timing rather than standard SPI protocols, this warning might be misleading. Eliminating or making this message friendlier when using WS2811 chains can prevent the confusion, as these strips are designed for bit-banged output rather than hardware SPI.

Souravgoswami · 2024-02-15T09:21:42Z

Using two ISR in my code reintroduced the flickering issue, even without defining SPI. I came across the WLED website that provided some guidance:

"All pins can be changed in the Hardware section of LED settings. Please note that these are GPIO numbers, please consult a pinout for your board to find the labeled pin (e.g D4 = GPIO2 on most ESP8266 boards). When using an ESP8266 board, it's recommended to use pins GPIO1, GPIO2, or GPIO3 for LED Data; using other pins will require bit-banging and may cause slow performance and/or issues elsewhere (such as with IR decoding)."

Source: https://kno.wled.ge/basics/getting-started/

Utilizing GPIO 2 eliminated the flickering, but when dimming the LEDs, severe flickering occurs. Additionally, this pin is linked to the ESP8266's onboard LED, which now remains constantly on.

Switching to GPIO 1 also fixed the initial flickering problem but resulted in similar dimming issues. Moreover, GPIO 1 outputs boot debug information, which I personally do not need but others might.

This situation has left me confused about the underlying cause of these issues.

EDIT:
I've notced that when my setup has an array of 10 to 50 CRGB LEDs, everything works smoothly, even with 50 LEDs connected. However, as the number of LEDs increases to 100, a noticeable flickering begins, even though 50 LEDs are connected. This flickering becomes more noticeable with 200 LEDs and significantly worsens with a setup of 300 LEDs.

Souravgoswami · 2024-02-15T17:36:16Z

I continue to encounter the same problem and have simplified my code to isolate the issue:

#pragma GCC optimize("Os")

#include <Arduino.h>
#include <FastLED.h>

#define NUM_LEDS 70
#define DATA_PIN 2
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void setup() {
  delay(1000);
  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  FastLED.show();
  FastLED.delay(1000);

  uint16_t flashDuration = random8(10, 25);
  for (uint16_t i = 0; i < flashDuration; ++i) {
    leds[0] = (random8(10) >= 5) ? CRGB::White : CRGB::Blue;
    FastLED.show();
    FastLED.delay(50);
  }

  uint8_t rapidFlashDuration = random8(10, 20);
  for (uint8_t i = 0; i < rapidFlashDuration; ++i) {
    leds[0] = (i % 2 == 0) ? CRGB::White : CRGB::Red;
    FastLED.show();
    FastLED.delay(50);
  }

  leds[0] = CRGB::Yellow;
  FastLED.show();
  FastLED.delay(1000);
}

With this setup, instead of illuminating only the first LED, it incorrectly lights up 3 - 4 LEDs in sequence with red, blue, yellow, and white colours. Upon connecting a different WS2811 LED chain, the issue disappeared, leaving me suspecting the original chain might be faulty. But when I tested the so-called faulty chain with an Arduino using the same code, no issues were noticed.

Considering a potential signal level mismatch, I used the TXS0108E level shifter to adjust the 3.3V signal from the ESP8266 to 5V, suitable for WS2811. The problem still persisted.

I speculated the issue might stem from signal reflection due to unterminated lines, especially since my setup involves configuring 70 LEDs while only having a 50 LED chain connected. Extending the chain with another WS2811 did not resolve the issue. Curiously, adjusting the NUM_LEDS to 69 in the code eliminates the problem, but reintroducing 70 LEDs brings the issue back, confirming it's not related to the power supply and such.

This anomaly suggests a deeper issue potentially related to how the FastLED library interfaces with the ESP8266, signal integrity, or specific characteristics of the WS2811 LED chain that are exacerbated under certain configurations.

EDIT:
With the exact same code, and even NUM_LEDS = 500 I faced no issues on Arduino nano - the issue is only present on ESP8266.

Souravgoswami · 2024-02-15T19:09:56Z

Note that #define FASTLED_ALLOW_INTERRUPTS 0 doesn't solve the issue for me:

#pragma GCC optimize("Os")

#define FASTLED_ALLOW_INTERRUPTS 0
#include <Arduino.h>
#include <FastLED.h>

#define NUM_LEDS 100
#define DATA_PIN 14
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void buttonPushEvent();

void setup() {
  delay(1000);
  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  FastLED.show();
  FastLED.delay(1000);

  uint16_t flashDuration = random8(10, 25);
  for (uint16_t i = 0; i < flashDuration; ++i) {
    leds[0] = (random8(10) >= 5) ? CRGB::White : CRGB::Blue;
    FastLED.show();
    FastLED.delay(50);
  }

  uint8_t rapidFlashDuration = random8(10, 20);
  for (uint8_t i = 0; i < rapidFlashDuration; ++i) {
    leds[0] = (i % 2 == 0) ? CRGB::White : CRGB::Red;
    FastLED.show();
    FastLED.delay(50);
  }

  leds[0] = CRGB::Yellow;
  FastLED.show();
  FastLED.delay(1000);
}

robertlipe · 2024-03-07T18:23:32Z

You have some harsh ringing on those rise times.. if you're getting a reflection in the cable, the symptoms can math. Toss a 110 or 220 ohm resistor after the shifter and before the strip. See if that fulls your over and undershoots and leaves you with less crazy rf-like behavior on that bus.

Technically, it'll lower your voltage slightly but more importantly, it'll get rid of the additive over and undershoots that can cause signal misreads. Optimizer setting, color patterns, pixel count, the number of cold drinks in the fridge, the added capacitance of your scope or a finger on the wire, and other crazy things can all move one bit which is enough to make these strands spaz.

Souravgoswami · 2024-12-20T22:43:26Z

Hi, sorry for the delayed reply. I've tried a 470 ohms and a 1k MFR resistor, which didn't fix the problem back then. IDK why it flickers, but it happened only on the one WS2811 chain. But the chain has been running great on 24x7 on an arduino since this issue was created. It's WS2811 specific chain on the D1 mini (tried two other boards with the same issue) that causes the issue. I'll try sometime to reproduce this issue on the latest version of FastLED as it contains various bug fixes related to flickering and such.

zackees · 2024-12-21T00:29:36Z

There's been questions on whether the ESP32 produces accurate timings from T1,T2,T3 format we use to T0H/L T1H/L needed by the espressif led-strip component.

Since a few versions ago I introduces manual adjustment of the LED timings for the WS2812 clockless chipset.

#ifndef FASTLED_WS2812_T1
#define FASTLED_WS2812_T1 250
#endif

#ifndef FASTLED_WS2812_T2
#define FASTLED_WS2812_T2 625
#endif

#ifndef FASTLED_WS2812_T3
#define FASTLED_WS2812_T3 375
#endif

These are include level defines, so you can override each of the T1,T2,T3 timings before you include FastLED.

Something like this:

#define FASTLED_WS2812_T1 255
#include "FastLED.h"

If this works for you, then please let me know, as it will have important ramifications.

Souravgoswami · 2024-12-21T06:10:58Z

Thanks for your reply!

It seems like the macros you mentioned are designed for WS2812?

template <uint8_t DATA_PIN, EOrder RGB_ORDER = GRB>
class WS2812Controller800Khz : public ClocklessController<
	DATA_PIN,
	C_NS_WS2812(FASTLED_WS2812_T1),
	C_NS_WS2812(FASTLED_WS2812_T2),
	C_NS_WS2812(FASTLED_WS2812_T3),
	RGB_ORDER> {};

But in my case, I’m using WS2811.

BTW, I set up a D1 mini I had lying around, added a 1k MFR resistor (wire-wound and some cheap CFR significantly distorts the waveform, and shows about 0.5uH at 100kHz on my LCR meter) on pin D5 (DATA_PIN 14 in the code), and used an LED light strip I bought a few months ago. It works fine on Arduino (I’ve used it before for decoration).

Unfortunately, the flickering issue is still there. I doubt simply setting FASTLED_WS2812_T1 to 250 or something similar won’t solve the problem since my setup uses WS2811 instead. It’s quite a strange issue!

robertlipe · 2024-12-21T07:00:24Z

Zachees, ESP8266 != ESP32.

You've said a couple of times ITT that the problem is fixed, but keeps coming back, so I've kind of lost the beat on whethere the softuart is implicated or if it's reproducible with exactly the cost that you posted, for example. (It'll never be reproducible for me because I don't do 8266.) 8266 is a single-core part without great DMA. If you're running softuart and other things demanding super accurate timing, it's not terribly surprising that you're just living on the edge, but that program doesn't look demanding. ESP32 is simply way more capable hardware and 8266 makes sense really in the most extremely price-sensitive (and limited) uses.

But it is odd that the scope shown above doesn't recognize the fundamental frequency as 800kHz. My cheapo scope gets it on the nose with any pattern, even all pixels set to zero as that's not really an idle state. It's worth capturing and measuring the individual pulse times to see if you're within spec. Is it that far off on your ATMega build? If you're really running a base freq of 734Khz instead of 800, that's almost 10% out of spec. I wouldn't be shocked if there are some strands that can cope with that and some that can't. Other than the EOF reset pulses, do you you show individual bit times that are out of spec when this occurs? Is it the entire chain or does it start downstream?

I don't know how they're diffrent in the FastLED code, but at a signaling level, modern 2811 and 2812 are the same. (There were 400Khz versions of each many years ago. Those are all but out of circulation.) The World Semi 2811 is the chip. The WS2812 integrates the chip and three LEDs into one package. 2811's are commonly used on >5V strips because it allows you to use multiple LEDs (that conveniently burn down to an integer divisor of the strip voltage) from a single chip. This is why high-voltage (>5) strips tend to have wide "pixels"; it's one chip controlling a bunch of LEDs.

Souravgoswami · 2024-12-21T08:35:29Z

But it is odd that the scope shown above doesn't recognize the fundamental frequency as 800kHz. My cheapo scope gets it on the nose with any pattern, even all pixels set to zero as that's not really an idle state. It's worth capturing and measuring the individual pulse times to see if you're within spec. Is it that far off on your ATMega build? If you're really running a base freq of 734Khz instead of 800, that's almost 10% out of spec. I wouldn't be shocked if there are some strands that can cope with that and some that can't. Other than the EOF reset pulses, do you you show individual bit times that are out of spec when this occurs? Is it the entire chain or does it start downstream?

Yeah, I’m not sure why, but on my bench storage scope, I get a similar result (no ringing, thanks to the 1k resistor):

The waveform in the scope flickers a bit, which makes sense since the waveform isn’t a perfect square wave. A logic-analyzer would probably give better insight.

Anyway, with the resistor in place and no ringing, I still notice random flickering on some lights using this code (FastLED 3.9.7):

#define FASTLED_WS2812_T1 250

#pragma GCC optimize("Os")

#define FASTLED_ALLOW_INTERRUPTS 0
#include <Arduino.h>
#include <FastLED.h>

#define NUM_LEDS 73
#define DATA_PIN 14
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void setup() {
  delay(1000);

  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  FastLED.show();
  FastLED.delay(1000);

  uint8_t flashDuration = random8(10, 25);
  for (uint8_t i = 0; i < flashDuration; ++i) {
    leds[0] = (random8(10) >= 5) ? CRGB::White : CRGB::Blue;
    FastLED.show();
    FastLED.delay(50);
  }

  uint8_t rapidFlashDuration = random8(10, 20);
  for (uint8_t i = 0; i < rapidFlashDuration; ++i) {
    leds[0] = (i % 2 == 0) ? CRGB::White : CRGB::Red;
    FastLED.show();
    FastLED.delay(50);
  }

  leds[0] = CRGB::Yellow;
  FastLED.show();
  FastLED.delay(1000);
}

In this current setup, the first LED flickers as expected, but oddly, the second LED in the chain also flickers randomly. This behaviour only occurs if I set the LEDs to >= 73. It doesn’t matter whether the chain itself has 50 or 100 LEDs; the flickering always starts when the code specifies >= 73.

Note that I’m not using a level shifter right now since it didn’t make any difference with the flickering issue.

out.mp4

It’s definitely random, and as I recall when I first encountered this issue, it was even worse - 5 to 6 LEDs in the chain would flicker starting from the first one.

Now, the flicker possibly happens with FastLED.show():

#pragma GCC optimize("Os")

#define FASTLED_ALLOW_INTERRUPTS 0
#include <Arduino.h>
#include <FastLED.h>

#define NUM_LEDS 160
#define DATA_PIN 14
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void setup() {
  delay(1000);

  FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  leds[1] = CRGB::Green;
  leds[2] = CRGB::Blue;
  FastLED.show();
  FastLED.show();
  FastLED.show();
}

With this code, the third LED (blue) and the one following it flicker in blue. Adding more show() calls causes even more flickering...

Interestingly, removing #define FASTLED_ALLOW_INTERRUPTS 0 fixed the issue this time, though I remember it didn’t make a difference in the past!

zackees · 2024-12-22T21:32:21Z

I recommend just using WS2812 driver, which is pretty much the same as WS2811.

If @robertlipe is right and the leds are running out of spec, then there is now an overclock feature which can adjust it back into spec.

See the readme and the big graphic, it will show you how it's done.

If this works for you or doesn't, please let us know.

Souravgoswami · 2024-12-27T17:03:56Z

Hi @zackees, I've already tried that and experimented with different timings, adjusting them within a range of ±1ns to ±5ns for each. For example:

#define FASTLED_WS2812_T1 250 # from 245 to 255
#define FASTLED_WS2812_T2 625 # from 620 to 630
#define FASTLED_WS2812_T3 375 # from 370 to 380
#include <FastLED.h>

If I set a value way too far out of range, like FASTLED_WS2812_T2 to 300, all the LEDs just turn white, red and yellow, so it seems the timing itself is working fine. But the main issue - the flickering lights remains the same. Adjusting timing helps a bit at times, but the fourth abnormally flickering light flickers a bit faster or slower, but doesn't go away completely even after adjusting the timings.

zackees · 2024-12-28T03:05:11Z

I've disabled RMT5 recycling on for all ESP32 boards an hour ago. Please download the FastLED library and import it into your project to see if it fixes it.

There will be a new release tomorrow where this is included as the default mode.

Souravgoswami · 2024-12-28T07:52:53Z

Thanks! Will this work on the ESP8266? Do I need to make any tweaks to my code? The issue I’m facing is with the ESP8266 (D1 mini) and WS2811 / WS2812 / WS2812B (tried all).

zackees · 2024-12-28T22:28:56Z

I know that ESP8266 runs with FastLED. The code changes are for Rmt 5.1, it's possible ESP8266 uses an older toolchain in which case RMT 4.x. will be compiled in automatically.

So it really depends whether you are on arduino, arduino cloud, or platformio etc... I really don't have enough information to tell you whether it will work or not. Please let me know though, because I am interested.

robertlipe · 2024-12-28T22:58:48Z

8266 is frozen at 3.x https://github.com/espressif/ESP8266_RTOS_SDK/releases It hasn't received an update in years and the last several updates were cherry-picks of big problems. Being stuck on 8266 is only slightly better than being trapped on Atmega. :-)

…

On Sat, Dec 28, 2024 at 4:29 PM Zachary Vorhies ***@***.***> wrote: I know that ESP8266 runs with FastLED. The code changes are for Rmt 5.1, it's possible ESP8266 uses an older toolchain in which case RMT 4.x. will be compiled in automatically. So it really depends whether you are on arduino, arduino cloud, or platformio etc... I really don't have enough information to tell you whether it will work or not. Please let me know though, because I am interested. — Reply to this email directly, view it on GitHub <#1599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36JPLAZNPW66D3LLVT2H4Q35AVCNFSM6AAAAABT76RSQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGUZDANZYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

zackees · 2024-12-28T23:01:29Z

Hi @zackees, I've already tried that and experimented with different timings, adjusting them within a range of ±1ns to ±5ns for each. For example:
#define FASTLED_WS2812_T1 250 # from 245 to 255
#define FASTLED_WS2812_T2 625 # from 620 to 630
#define FASTLED_WS2812_T3 375 # from 370 to 380
#include <FastLED.h>
If I set a value way too far out of range, like FASTLED_WS2812_T2 to 300, all the LEDs just turn white, red and yellow, so it seems the timing itself is working fine. But the main issue - the flickering lights remains the same. Adjusting timing helps a bit at times, but the fourth abnormally flickering light flickers a bit faster or slower, but doesn't go away completely even after adjusting the timings.

I'm sorry, I didn't realize the old toolchain you mentioned until just now. Yeah. I don't work these older devices so I depend on user contributions for improvements to these areas.

Souravgoswami · 2024-12-29T19:52:20Z

Hello @zackees, could you please provide more details? Why is the version frozen? The home-page readme clearly states support for the ESP8266:

ESP8266 using the Arduino board definitions from http://arduino.esp8266.com/stable/package_esp8266com_index.json - please be sure to also read https://github.com/FastLED/FastLED/wiki/ESP8266-notes for information specific to the 8266.

zackees · 2024-12-29T22:27:04Z

Espressif froze it, not us. We do support ESp8266 and it's used quite a bit. I'm not sure what's going on here.

Souravgoswami · 2024-12-29T22:55:29Z

Thanks for the reply! I'm using Arduino IDE v2.3.4, and it seems like I'm using the latest library. I also got the update for 3.9.8. I've selected the D1 mini board and ran this code:

#include <FastLED.h>
#define STRINGIFY(x) #x
#define _STRINGIFY(x) STRINGIFY(x)
#pragma message("FastLED Version: " _STRINGIFY(FASTLED_VERSION))
...

And it prints:

/home/sourav/Downloads/sketch_dec21a/sketch_dec21a.ino:13:64: note: '#pragma message: FastLED Version: 3009008'
   13 | #pragma message("FastLED Version: " _STRINGIFY(FASTLED_VERSION))

So, it looks like I'm indeed running version 3.9.8 and not using FastLED from the ESP8266 library itself.

zackees · 2024-12-30T21:22:41Z

Is there any older version of FastLED that works?

Souravgoswami · 2024-12-30T22:02:39Z

I tried versions 3.3.3, 3.5.0, 3.6.0, 3.7.0, 3.7.8, and 3.9.8. Starting from 3.7.0, I noticed the flickering became faster. Before 3.7.0, the flickering was slower - wrong LEDs would blink after 2 - 3 seconds, stay lit for another 2 - 3 seconds, and then turn off and on again.

Currently, I have 3 LED chains of WS2811 hooked up. The wires are kept short to prevent any unwanted signal reflection and include a 1k MFR. Two of the chains flicker, while one does not. With a parallel data connection, the effect should be mirrored across all chains, but I'm seeing that the colours of the flickering LEDs on the two chains don't match each other.

Code as before:

#pragma GCC optimize("Os")

#define FASTLED_ALLOW_INTERRUPTS 0
#include <Arduino.h>

#include <FastLED.h>
#define STRINGIFY(x) #x
#define _STRINGIFY(x) STRINGIFY(x)
#pragma message("FastLED Version: " _STRINGIFY(FASTLED_VERSION))

#define NUM_LEDS 160
#define DATA_PIN 14
#define BRIGHTNESS 100

CRGB leds[NUM_LEDS];

void setup() {
  delay(1000);

  FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
  FastLED.setBrightness(BRIGHTNESS);
  FastLED.clear();
}

void loop() {
  leds[0] = CRGB::Red;
  leds[1] = CRGB::Green;
  leds[2] = CRGB::Blue;

  FastLED.show();
  FastLED.show();
  FastLED.show();
  FastLED.show();
  FastLED.show();
  FastLED.show();
  FastLED.show();
  FastLED.show();
}

zackees · 2024-12-31T02:09:49Z

Thanks, this is good to know.

zackees · 2024-12-31T02:10:29Z

So the flickering started before I came on the project....

zackees closed this as completed Dec 28, 2024

zackees closed this as not planned Won't fix, can't repro, duplicate, stale Dec 28, 2024

zackees reopened this Dec 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Flickering on ESP8266 3.1.2 and 3.1.1 #1599

Flickering on ESP8266 3.1.2 and 3.1.1 #1599

Souravgoswami commented Feb 14, 2024

Souravgoswami commented Feb 14, 2024

Souravgoswami commented Feb 15, 2024 •

edited

Loading

Souravgoswami commented Feb 15, 2024 •

edited

Loading

Souravgoswami commented Feb 15, 2024

robertlipe commented Mar 7, 2024 •

edited

Loading

Souravgoswami commented Dec 20, 2024 •

edited

Loading

zackees commented Dec 21, 2024

Souravgoswami commented Dec 21, 2024

robertlipe commented Dec 21, 2024

Souravgoswami commented Dec 21, 2024 •

edited

Loading

zackees commented Dec 22, 2024

Souravgoswami commented Dec 27, 2024

zackees commented Dec 28, 2024

Souravgoswami commented Dec 28, 2024 •

edited

Loading

zackees commented Dec 28, 2024

robertlipe commented Dec 28, 2024 via email

zackees commented Dec 28, 2024

Souravgoswami commented Dec 29, 2024 •

edited

Loading

zackees commented Dec 29, 2024

Souravgoswami commented Dec 29, 2024

zackees commented Dec 30, 2024

Souravgoswami commented Dec 30, 2024 •

edited

Loading

zackees commented Dec 31, 2024

zackees commented Dec 31, 2024

Flickering on ESP8266 3.1.2 and 3.1.1 #1599

Flickering on ESP8266 3.1.2 and 3.1.1 #1599

Comments

Souravgoswami commented Feb 14, 2024

Souravgoswami commented Feb 14, 2024

Souravgoswami commented Feb 15, 2024 • edited Loading

Souravgoswami commented Feb 15, 2024 • edited Loading

Souravgoswami commented Feb 15, 2024

robertlipe commented Mar 7, 2024 • edited Loading

Souravgoswami commented Dec 20, 2024 • edited Loading

zackees commented Dec 21, 2024

Souravgoswami commented Dec 21, 2024

robertlipe commented Dec 21, 2024

Souravgoswami commented Dec 21, 2024 • edited Loading

zackees commented Dec 22, 2024

Souravgoswami commented Dec 27, 2024

zackees commented Dec 28, 2024

Souravgoswami commented Dec 28, 2024 • edited Loading

zackees commented Dec 28, 2024

robertlipe commented Dec 28, 2024 via email

zackees commented Dec 28, 2024

Souravgoswami commented Dec 29, 2024 • edited Loading

zackees commented Dec 29, 2024

Souravgoswami commented Dec 29, 2024

zackees commented Dec 30, 2024

Souravgoswami commented Dec 30, 2024 • edited Loading

zackees commented Dec 31, 2024

zackees commented Dec 31, 2024

Souravgoswami commented Feb 15, 2024 •

edited

Loading

Souravgoswami commented Feb 15, 2024 •

edited

Loading

robertlipe commented Mar 7, 2024 •

edited

Loading

Souravgoswami commented Dec 20, 2024 •

edited

Loading

Souravgoswami commented Dec 21, 2024 •

edited

Loading

Souravgoswami commented Dec 28, 2024 •

edited

Loading

Souravgoswami commented Dec 29, 2024 •

edited

Loading

Souravgoswami commented Dec 30, 2024 •

edited

Loading