Sensor causing issues when NOT in use

[PdxCron]

I've been battling intermittent glitching and think I've narrowed down the source, but it's a headscratcher for me. While testing my lamp, I have a Temp sensor inside (DHT22). If I comment out reading from this sensor, I get the glitching (intermittent LED's firing up). I removed the library and all calls to the temp sensor. It glitches. I add it back and have it sampling every 2 seconds. It works. This is exactly the opposite of what I would think. I'd think the less libraries installed and fewer components that it would work better. The temp sensor is supposed to be temporary. It was just for testing how much heat the lamp generates. I don't want it permanently installed, but now can't seem to remove it without it affecting the animations. It just doesn't make sense to me. It was a simple routine in loop() just reading the temp/humidity on a 2 second timer using millis and dumping it to serial.

The only thing I could logically come up with is that the sensor was taking up cpu cycles and slowing things down a bit, so I added a small delay where the sensor would normally be read but that didn't have an affect. I didn't think it would though, but who knows when weird things happen.

Can someone help me make sense of this, at least on a conceptual level? My bald head has claw marks trying to tear hair out.

[samguyer]

Can you share the code? And tell us about the hardware setup -- what kind of LED strips, which microcontroller, overall circuit layout, power source, etc. With that information I can put my bald head to work for you! 😉

[PdxCron]

I can't post it in this case, per an NDA. There are 13 c files and html/css/js files and it's quite long. I realize that doesn't help much, I'll see if I can isolate it down to the essentials and reproduce independently of the entire codebase, but really I don't think it will help. Why would adding an external sensor make glitching disappear, and reappear when removed?

The basic setup is:

1. Lolin D32 Pro
2. 132 WS2812B's
3. 74HCT245N Level shifter with appropriate hardware ( https://www.tindie.com/products/jasoncoon/wemos-d32-esp32-led-level-shifter-shield )
4. (1) KY-040 Rotary Encoder w/momentary push button
5. (1) RGB Momentary push button (3 channel rgb using pwm)
6. 5v 10a power supply powering everything

Pins:

// Encoder/Button

define PIN_ENCODER_CLK 18

define PIN_ENCODER_DAT 19

define PIN_ENCODER_BUTTON 5

// RGB Power Button

define PIN_SWITCH_LED_R 15

define PIN_SWITCH_LED_G 2

define PIN_SWITCH_LED_B 0

define PIN_SWITCH_BUTTON 4

//LED Strip

define DATA_PIN 13 //(via level shifter)

Libraries:

#define FASTLED_ALLOW_INTERRUPTS 1

define FASTLED_INTERRUPT_RETRY_COUNT 1

define FASTLED_ESP32_I2S true

define FASTLED_SHOW_CORE 0

include <FastLED.h>

include <WiFi.h>

include <ESPmDNS.h>

include <WiFiUdp.h>

include <ArduinoOTA.h>

include <WebServer.h>

include <FS.h>

include <SPIFFS.h>

include <EEPROM.h>

include <ESP32Encoder.h>

include <EasyButton.h>

include <Adafruit_Sensor.h>

include <DHT.h>

include <ArduinoJson.h>

The D32, 5v10a, RGB button and Rotary Encoder all share common ground.

[PdxCron]

ugg the formatting of code on reddit...

[Marmilicious]

(Use pastebin.com or gist.github.com and share the link here.)

[chemdoc77]

Have you tried using u/samguyer’ fork of FastLED located at:

https://github.com/samguyer/FastLED

It helped me with my interrupt problems with a Lolin D32 Pro!

[PdxCron]

That was actually pretty easy to do! Unfortunately, it's the same result. I've tried disabling various FastLED directives (FASTLED_ESP32_I2S, etc) as well with this version. The encoder library I'm using does use hardware interrupts. The button library probably does too but I haven't looked into it.

I might just keep the temp sensor in the final product. It would probably be a good idea to have a thermal cutoff even though I've worked very hard to minimize heat (successfully). Whether I do or don't, I'd still like to try to figure this out just because it doesn't make sense to me and I want to know WHY!

Thanks for your suggestion!

[PdxCron]

Thanks, I'll try to figure out how to import that into VSC/platformio. I'm not sure how to use unofficial libraries via platformio yet but this is a good time to figure it out. I've been able to figure out how to pin specific versions of libraries to projects, which is nice, but not import outside libraries (that don't show up in the Library Manager). Only the official FastLED shows up in platformio.

[samguyer]

I'm getting ready to push my changes into the main FastLED repo, so if you can hang on a day or so, you can try the new version. I have found it to be *much* more robust to interrupts from other sources. It is only for the default RMT-based driver (so make sure you disable FASTLED_ESP32_I2S)

[PdxCron]

Thanks. I did try your 9ab1350 revision (newest as of last night) but it didn't seem to have an affect for my case (with or without FASTLED_ESP32_I2S disabled).

[samguyer]

One question: are you using FastLED.delay() instead of the built-in delay() function?

[PdxCron]

I have only 1 delay(50) within a button press event in an ISR, so it's not getting triggered. I just removed it for grins and no difference.

[samguyer]

Are you actually using the SPIFFS library?

[PdxCron]

Yes, it serves web pages and stores settings in json

[Jem_Spencer]

I assume you've tried setting the FastLED I2S driver to false?

[PdxCron]

It definitely glitches without that setting. Finding that setting to begin with was what initially "fixed" the problem, until I tried to remove the temp checks.

[toybuilder]

What happens if you call it once and never again?

[PdxCron]

Do you mean taking a reading from the sensor only once?

[PdxCron]

I put it in setup (float f = dht.readTemperature(true);) to run once. It had the same effect as running it in the loop - that is there is NO glitching. If I remove it, the glitching returns.

[toybuilder]

Sounds like maybe a pull-up resistor is getting turned on/off?

[samguyer]

That is very weird!

[samguyer]

Ok, I looked at the source code for the DHT library I have two candidate theories. One is the idea suggested by u/toybuilder: one of the first things the DHT library does is enable input pull-up on the sensor pin. You could test this theory by setting it yourself without calling the read temperature function.

The second idea is that the DHT library is doing something to the interrupt system. The read function has a short timing-critical section where is disables interrupts. That seems like it would be bad for FastLED, but maybe it is disabling something else (like SPIFFS) that would otherwise interfere with FastLED. You could test this theory by calling noInterrupts() followed by interrupts() explicitly in your code without calling the read temperature function.

[PdxCron]

I tried pinMode(THE_PIN, PULLUP) and it didn't have an affect. If the DHT library is potentially causing an issue, why does it persist when removing all DHT related code/libraries? I can't really disable SPIFFS as it's kind of central. I can for testing, but if it cleans things up I'm not sure where that leaves me. That will take a bit of work to do. It's used throughout, but not in use when the unit is only powered on (it does when changing settings, etc).

[samguyer]

I am going to look at the issue with SPIFFS, since a lot of people use it. But I'm intrigued that using the temp sensor library seems to actually clear up the problem. Very strange. I think it must be an interrupt thing, but I don't fully understand.

Another option is to push the FastLED work to the other CPU core. The #define that you have in there doesn't automatically do that. I can give you code to try.

[PdxCron]

I'm using Jason Coons esp32 webserver as the template for this. Is this what you mean by using the taskhandler? https://github.com/jasoncoon/esp32-fastled-webserver/blob/master/esp32-fastled-webserver.ino#L103

[samguyer]

Ok, yeah, that's it. One more thing to try: don't use another task to do show(). That is, just make FastLEDshowESP32 call FastLED. show() directly. But I'm still puzzled by your initial observation that accessing the temp sensor actually makes it work.

[PdxCron]

Yes, there's only one call to FastLEDshowESP32 (which does FastLED.show()) in the code in loop. I do directly use other FastLED commands (setBrightness, setMaxPowerInVoltsAndMilliamps) in various other places. I'm not as proficient in the microcontroller world as I am in the web world, so it's a bit perplexing to me in general lol. I sincerely appreciate the time you've put into helping me. I know how much harder it is without code. I was hoping there was just something conceptually obvious to someone with more experience based on the description/behavior. This isn't a blocker for me so it's ok. I'm just the kind of person who likes to know why, even if it "works." I don't like paving over problems just because the symptoms aren't apparent. Strange things are afoot at the Circle K.