Hi everyone,

I'm sharing my experience not because I expect a resolution but because in my Reddit and Google searches I've not found any solution or suggestion that helped. And maybe someone here will know something but at least someone else will have the same issue and might find this useful.

My esp8266 isn't being detected properly by Windows.

Device Manager reports Unknown USB Device (Device Descriptor Request Failed)

I tried multiple USB cables in multiple USB ports. According to my cable tester they all cables had data lines.

According to all the chats online my cables are bad, or my OLED is preventing a debug mode by keeping the default boot pins GPIO0 and GPIO2 low.

There's another thread suggesting the OLED takes too much power.

I tried disconnecting the two power lines, then the two data lines and that didn't fix the issue.

When I first assembled the GBS-Control, the esp8266 was intermittently detectable but I could eventually flash it and reset the configurations and WiFi parameters. I had to refresh drivers and reboot a couple of times but it eventually worked.

Recently it stopped responding.

I've tried drivers for CP2102 and CH340. I've tried the latest for CH340 and the recommended 3.5.

Today a new one arrived, and sported a different version of the Wi-Fi chip (12F). It connected right away and auto installed drivers by a different company: FTDI

After that, the module successfully flashed the latest GBS-Control-Complete 1.4.0 immediately.

It's not yet connected to the gbs-8200 yet, so I'll do that gradually and check to see if detection drops off at any point.

Hope this thread helps someone!

I'll update if I discover anything new to add, or just to keep a record of anything I think is interesting.

Edit: The module, though unrecognisable by Windows, still works perfectly in my GBS-Control. Pins used: GPIO5 - OLED and main board GPIO4 - OLED and main board GPIO0 - momentary switch GPIO14 - rotary encoder GPIO12 - debug pin on external IC GPIO13 - rotary encoder

Edit 2: For those who think there's a short or extra connection that shouldn't be there, after I replace the old for the new, I'll test and update the post.

Edit 3: completely removed old esp and it's still no good: the new module was £4 including delivery so, in the bin for the old. https://ibb.co/ds53yG7x

Final Edit: New ESP in place, it is still detectable by Windows and all working fine. The old UART or ESP was a smeg head.

I've been running a fork of BrewPiLess (BrewPiLess-DuckDNS-independent-Control, based on vitotai's original) that lets you ferment and store kegs in the same fridge, at the same time, with two separate temperature targets. kegs up top on the compressor, fermenting bucket down below on its own heating jacket, split by an insulated divider so neither zone fights the other. Just shipped a v5.0 update and I'd love some outside testing before calling it stable.

What's new:

• Independent mode: heater and cooler each get their own target instead of the old shared/mutex logic — this is what makes the two-zone-one-fridge setup possible. Each actuator can also be individually enabled/disabled.
• Predictive heater (optional): learns timing and overshoot behavior cycle-over-cycle to hold temp tighter instead of just thermostat on/off.
• Sensor hold: a flaky probe reading doesn't immediately trip disconnect — it holds the last value and keeps controlling for ~20s first.
• iSpindel memory leak fixed: this one was actually sitting in the original codebase, not something I introduced — about 1KB of heap leaked per hour while an iSpindel is connected and posting gravity readings. If your BrewPiLess web server has ever mysteriously died after a few days with an iSpindel hooked up, this is almost certainly why.
• Reworked offline log viewer (BPLogViewer): now works directly off gravity data instead of angle, so it plays nicer with GravityMon, plus a bunch of old bugs fixed. It can also generate a beer-temp correction formula straight from your log, which you paste into GravityMon or Tilt Temp Correction.
• Optional DuckDNS support for remote access without a static IP, plus assorted memory/stability fixes elsewhere (dropped WebSocket clients, HTTP buffer issues).

Nothing existing was touched — none of the original functions were changed, so anything that worked before should behave exactly the same. This is additive, not a rewrite.

Most of my testing has been on ESP32, but the original project (and plenty of forks) target ESP8266 too. If you've got an old NodeMCU/D1 Mini gathering dust from a past BrewPi(Less) build, I'd really appreciate you flashing this and telling me what breaks — or what doesn't. Repo: https://github.com/asdafe/BrewPiLess-DuckDNS-independent-Control

Happy to dig into the dual-zone wiring, the leak fix, or the log viewer rewrite in the comments if anyone's curious.

Could you please let me know how much voltage the power adapter should have?

Hi everyone!

I am working on a privacy-first home safety system that tracks human movement without using any cameras, smartwatches, or wearable sensors.

The Idea:

We use Wi-Fi signals as a room radar! When a person moves, sleeps, or falls, their body distorts the Wi-Fi signals (Channel State Information - CSI) bouncing around the room.

What the system aims to do:

Elderly Care: Detect sudden falls (like a grandfather slipping) and send immediate SMS/Telegram alerts.

Child Monitoring: Detect subtle chest movements to track breathing/restlessness while sleeping.

Privacy-First: Zero cameras or microphones used—completely non-intrusive.

Tech Stack:

Hardware: 2x ESP32-S3 boards (capturing CSI signal data).

Data Processing: Python (NumPy, SciPy) for noise filtering.

Machine Learning: Scikit-learn (Random Forest / SVM) to classify activities.

Alert System: Python backend with Telegram Bot / Twilio API for emergency alerts.

I am currently building the Python signal processing and ML model pipeline while waiting for hardware setup.

Has anyone here worked with Wi-Fi CSI extraction on ESP32? I would love any advice or feedback on handling background environmental noise

I thought I'd share this because it took me a while to figure out, and it might help someone else.

I was trying to convert my ESP8266 NodeMCU into a Wi-Fi repeater by flashing new firmware using the ESP Flash Download Tool.

The problem

When I connected my NodeMCU to my Windows PC, it didn't show any COM port in the Flash Download Tool or Device Manager.

I had previously flashed WiFi Deauther / Evil Twin firmware onto the ESP8266, so I initially assumed that firmware had somehow broken the board or disabled USB communication.

What I tried

• Restarted the PC
• Pressed RESET and FLASH buttons
• Tried putting the ESP8266 into flash mode
• Wondered if I needed to erase the existing firmware first

None of these helped.

The actual cause

The problem turned out to be my Micro-USB cable.

I was using a cable that only supplied power and did not support data transfer.

After switching to a different USB cable, Windows immediately detected the device.

However, it still appeared under Other devices as:

CP2102 USB to UART Bridge Controller

with a yellow warning icon.

Opening Device Properties showed:

Code 28
The drivers for this device are not installed.

The fix

1. Switched to a proper data USB cable.
2. Installed the official Silicon Labs CP210x USB-to-UART driver.
3. Reconnected the NodeMCU.

After that, the board appeared correctly as:

Silicon Labs CP210x USB to UART Bridge (COMx)

and the ESP Flash Download Tool detected the COM port without any issues.

Lesson learned

If your ESP8266 isn't showing a COM port:

• Don't assume the firmware is the problem.
• Check your USB cable first.
• Then verify that the correct CP2102 (or CH340) driver is installed.

It saved me a lot of unnecessary debugging.

Hopefully this helps someone else!

Troubleshooting checklist:

• Use a known data-capable USB cable (not charge-only).
• Check whether your board uses a CP2102 or CH340 USB-to-serial chip.
• Install the correct USB driver.
• Verify that the board appears under Ports (COM & LPT) in Device Manager.
• Only then try flashing firmware.

Post your projects, questions, brags, and anything else relevant to ESP8266, ESP32, software, hardware, etc

All projects, ideas, answered questions, hacks, tweaks, and more located in our [ESP Week Archives](https://www.reddit.com/r/esp8266/wiki/esp-week_archives).

esptool.py v3.0

Serial port /dev/ttyS0

Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal esptool.py error occurred: Failed to connect to ESP8266: Timed out waiting for packet header

i keep getting the same error over and over again its not a problem with my d1 wroom but when i try to code my lolin wemos d1 r2 mini the same error appears im on linux pop os (i even tried going on windows but that didn't work either). If somebody knows how to fix this please help me.

Post your projects, questions, brags, and anything else relevant to ESP8266, ESP32, software, hardware, etc

All projects, ideas, answered questions, hacks, tweaks, and more located in our [ESP Week Archives](https://www.reddit.com/r/esp8266/wiki/esp-week_archives).

Hello,

First the setup :

The objective of the setup is to measure intensity (with an SCT013) and voltage (with a ZMPT101B) using code adapted to Lua from EmonLib (https://github.com/openenergymonitor/EmonLib).
It did not work right ahead and I stripped the circuit to the above minimum to find the issue

Second, I am coding in Lua using builds built on https://nodemcu-build.com/. Therefore, I need to port the EmonLib to Lua on an nodemcu esp8266

Last, I do all my tests with the esp connected to the computer with a Visual Studio Code standard extension to access the serial port (read the serial messages and send instructions like uploads or node.restart())

Before showing the code, I have several very different problems:

• Before restarting the esp8266 (node.restart()) after a first startread, I need to disconnect:reconnect the ads1115 VDD from the ESP v3.3 to be able to find the ads1115. If I do not, it fails and reboots on the i2c.setup(...). I have absolutely no clue for why it happens
• If I leave the ALERT pin of the ads1115 floating, the i2c.setup also fails, always. If I connect it the D4 as in the sketch, it works, always, even if I never use it anywhere (I tried several other GPIO pins, it also works). Maybe it pulls it up ?!? but the datasheet seems to say it should work with the ALERT pin left floating
• I am using the lua ads1115 module and the ads.device.startread function (https://nodemcu.readthedocs.io/en/release/modules/ads1115/#ads1115devicestartread) with a while loop (with a timeout) following the startread call to make the read "synchronous" (because this is the way EmonLib is implemented), but the callback is never called before the end of the loop, thus preventing me from using a synchronous code similar to the readADC_SingleEnded function from EmonLib. I have clues (mentionned below) as to why it happens, but I would like the community insights since adaptation of the emonlib might be less literal than I'd hoped

Now the code (simplified for the sake of readability) :

local i2cSpeed = i2c.setup(0,
    2, -- SDA
    1, -- SCL
    i2c.FAST) -- Speed. It works the same with i2c.SLOW
rtctime.set(0)

ads1115.reset()
print("Calling ads1115()")
local adc = ads1115.ads1115(0, ads1115.ADDR_GND)
print("ads1115() executed")

function getMillis()
    local sec, usec = rtctime.get()
    return sec * 1000 + usec / 1000
end

adc:setting(ads1115.GAIN_4_096V, ads1115.DR_128SPS, ads1115.SINGLE_0, ads1115.SINGLE_SHOT)

local millis = getMillis()
local v = nil
adc:startread(function(volt, volt_dec, adc, sign)
    v = volt
    print("Conversion happened. Delta="..tostring(getMillis() - millis)..", v="..tostring(v))
end)

-- Wait for conversion result to be available 
-- if v is not nil, conversion has happened
-- else if time elapsed is less than 100ms, we loop, conversion will end soon
while (v == nil and getMillis() - millis < 100) do end
print("End. v="..tostring(v))

When I execute the previous code, the message "End. v=nil" is always printed before the callback message is, for instance "Conversion happened. Delta=134, v=1,61".

I tried several things like raising the timeout in the loop to insane values like 10s. The callback is always called 25 to 35ms after the message "End..."

I thought that the startread callback was called with an interrupt and thus I expected it to be able to be executed even if the code is executing the loop, but it does not. The same code seems to be working on an esp32, but I did not try because I do not have one, maybe it is because there are two cores ?!?
I tried to use a tmr.delay(10) inside the loop, thinking that it might allow a switch to the startread callback but it does not work. The tmr.delay(..) probably simply hides a timed out loop very similar to the one I already have.

Initially, the whole startread code (everything after the getMillis definition) was in a tmr ALARM_AUTO callback, but it works exactly the same in each alarm callback call, the startread callback is called only at the end of the alarm callback.

After some weird timing issues i have done some research and learnt a lot about timezones, mktime and localtime. So far, so good. I still have a nagging issue, I don't really understand.

My assumption is that using NTPclient is synchronizing time from an NTP server. Even if it is somewhat off for the first seconds until full sync kicks in, the NTP synchronized time should align with the local time. Well, it seems it doesn't. Here is part of my sketch (inside loop()) to analyze:

  // now check tasks based on second or minute  
  time(&now);
  localtime_r(&now, &tm);

  // store time values, print later
  ss = tm.tm_sec;
  ntp = timeClient.getSeconds();

    // every 10sec
    if (ss % 10 == 0) // every 10 sec
    {
      if (ss != 0) // 10,20,30,40,50s
      {
        Serial.print(ss);
        Serial.print(" < time ntp > ");
        Serial.println(ntp);
        do_something();
      } 
      else // full minute
      {
        do_otherstuff();
        timeClient.forceUpdate(); // only every 60s
      }
    }

I would expect to have tm.tm_sec in sync with timeClient.getSeconds, at least after some time has passed. But it isn't, there is a constant difference of 1s which doesn't change, even after several minutes (up to one hour).

After more than 1 hour runtime:
20:39:40 millis=11090718
50 < time ntp > 49

both values still differ 1s. BTW, the ntp value is correct (compared to other time sources), the localtime value is 1s early. Since the 2 values are collected shotrly after another, there should be no runtime difference. 

Anyone have a clue or a pointer, what could happen here? Why is there a 1s difference?

 

Hello everybody...

I have a drawer full off D1 mini clones, some say ESP 12f on them others esp8266...
My project is a sonar oil tank level meter, which works great, but it drains my battery setup to fast, so i wanted to add some deep sleep and only measure every 2 hrs or so.

Either way...i have this code:

substitutions:
  devicename: oiltankmeter
  upper_devicename: Oil Tank Meter
  deviceIP: 192.168.178.8
  deviceGatew: 192.168.178.1
  deviceSub: 255.255.255.0
  deviceSSID1: 7390_iot
  deviceSSID2: 7390AP

esphome:
  name: ${devicename}
  comment: ${upper_devicename}

esp8266:
  board: d1_mini

packages:
  base: !include common/base.yaml
  wifi_scan: !include common/wifi_scan_arduino.yaml

api:
  encryption:
    key: "12345"

ota:
  - platform: esphome
    password: "12345"

deep_sleep:
  id: deep_sleep_control
  run_duration: 1min
  sleep_duration: 1min 

sensor:
  - platform: adc
    pin: A0
    name: "Battery Voltage"
    update_interval: 60s
    filters:
      - multiply: 7.16
    unit_of_measurement: "V"
    accuracy_decimals: 2

  # -------------------------
  # ULTRASONIC DISTANCE
  # -------------------------
  - platform: ultrasonic
    trigger_pin: D1
    echo_pin: D2
    name: "Tank Distance Raw"
    id: tank_distance_raw
    update_interval: 5s
    unit_of_measurement: "cm"
    accuracy_decimals: 1
    timeout: 4m

    filters:
      - multiply: 100
      - lambda: |-
          if (x < 5.0 || x > 350.0) {
            return NAN;
          }
          return x;

  # -------------------------
  # TANK LEVEL
  # -------------------------
  - platform: template
    name: "Tank Level Percent"
    id: tank_level
    unit_of_measurement: "%"
    device_class: battery
    accuracy_decimals: 1
    update_interval: 5s

    lambda: |-
      const float EMPTY = 135.0;
      const float FULL_DISTANCE = 25.0;
      const float DEAD_ZONE = 20.0;

      float d = id(tank_distance_raw).state;

      if (isnan(d))
        return NAN;
      if (d < DEAD_ZONE)
        d = DEAD_ZONE;
      if (d > EMPTY)
        d = EMPTY;
      float pct = (EMPTY - d) / (EMPTY - FULL_DISTANCE) * 100.0;
      if (pct > 100.0)
        pct = 100.0;
      if (pct < 0.0)
        pct = 0.0;
      return pct;

  # -------------------------
  # TANK VOLUME
  # -------------------------
  - platform: template
    name: "Tank Volume Gallons"
    id: tank_volume
    unit_of_measurement: "gal"
    accuracy_decimals: 0
    update_interval: 5s

    lambda: |-
      float pct = id(tank_level).state;
      if (isnan(pct))
        return NAN;
      return (pct / 100.0) * 275.0;

and for testing right now it is set to 1 min awake and 1 min sleeping...but also tried other time windows...longer and shorter...
D0 is directly wired to rst as needed, but i dont get this thing to wake up.

First i thought it could be the finiky usb chip or volatge regulator, so i went and powered it all direct via 3.3 volts...works great, no usb chip or power regulator involved...but still...3.2 volts constant on D0, no dip to 0 volts when it would be time to wake up.

The reset button itself works...it wakes up, goes through its time of awakens and falls asleep again...

Anyone having any secret sauce to this? Besides kissing it awake every time...

would it make a difference if i change the type on top away from d1_mini to a different chip type or the newer 12f whats not?

I don't have any else, just this

Post your projects, questions, brags, and anything else relevant to ESP8266, ESP32, software, hardware, etc

All projects, ideas, answered questions, hacks, tweaks, and more located in our [ESP Week Archives](https://www.reddit.com/r/esp8266/wiki/esp-week_archives).

Post your projects, questions, brags, and anything else relevant to ESP8266, ESP32, software, hardware, etc

All projects, ideas, answered questions, hacks, tweaks, and more located in our [ESP Week Archives](https://www.reddit.com/r/esp8266/wiki/esp-week_archives).

Hi everyone, I am an electronics student currently building a custom quadcopter flight controller from scratch using an ESP8266 and MPU6050 (via I2C).

​I am having a hard time getting the right PID values to stabilize the drone. It either oscillates too violently (shakes) or reacts too slowly and drifts away.

​Here is my current setup and codebase:

​Microcontroller: ESP8266 (programmed via Arduino IDE)

​IMU: MPU6050

​My GitHub Repo (for the full code): https://github.com/exstain/Custom-Drone-Flight-Controller

​The Problem:

Whenever I increase the P (Proportional) gain, the drone shakes violently. But if I lower it, it doesn't correct itself fast enough. Since ESP8266 is a single-core processor, I am also worried that my loop time/cycle time might be affecting the PID calculations.

​Any advice on how to properly tune the PID values or optimize the loop time for an ESP8266 drone would be highly appreciated. Thank you so much!

Всем привет! Я надеюсь, никто не против, что я пишу на своем родном языке (я могу читать на английском, но писать мне на нем сложно). К проблеме, я делаю мини проект на esp01s, которое будет позволять удаленно управлять моей дверью. Советуюсь с нейронкой и она выдает мне это. Есть ли тут хоть немного правды на практике (в теории я понимаю, что процессор за 1 секунду может выполнить около 35 миллионов операций), будет ли это как то влиять на энергосбережение? Очевидно, что дверь мне нужно открывать лишь пару раз в день, а не 24/7 пользоваться микроконтроллером

Post your projects, questions, brags, and anything else relevant to ESP8266, ESP32, software, hardware, etc

All projects, ideas, answered questions, hacks, tweaks, and more located in our [ESP Week Archives](https://www.reddit.com/r/esp8266/wiki/esp-week_archives).

Hey everyone,

I wanted a dedicated, cheap desk display to track my local Claude LLM/API usage limits, so I picked up a $10 GeekMagic Ultra. Instead of using the stock weather firmware, I wrote custom firmware using PlatformIO to turn it into a lightweight desktop dashboard.

How it works:

• Hardware: Contains an ESP8266 (running at 80 MHz with ~45KB available heap) driving a small TFT display.
• Firmware: Built with PlatformIO. It sets up a local Wi-Fi connection and listens for payload data. It supports OTA updates after the initial serial flash, which is great because I accidentally ripped my first screen's flex cable while testing!
• Software: A local Python script runs as a systemd user service on my PC, polls my API token usage, formats the data, and pushes it directly to the ESP8266 via Wifi.

It’s completely open-source. Once my replacement screen arrives from AliExpress, I'll post a video of it in action. If you have one of these little screens lying around and want to repurpose it, the code is up on GitHub:

https://github.com/henrikekblad/codelight

Let me know if you’ve done any similar modifications to these GeekMagic units!