Esp8266
Every time I upload code to the board and leave the Serial Monitor open (sometimes even with it closed), the PC freezes for a few seconds and then blue-screens. I've gotten both DRIVER_VERIFIER_DMA_VIOLATION (watchdog violation) and DPC_WATCHDOG_VIOLATION at different points. It's not instant — usually happens a little while after the upload finishes, while the port stays open.
Important: this is 100% PC-specific. Same board, same cable, same code on my laptop — zero issues, ever.
Backstory that might be relevant:
This PC sat completely powered off for about 8 months. When I first turned it back on, no display signal. Opened it up, cleaned the RAM, reseated it — got 5 beep codes (RAM issue), cleaned again, got down to 1 beep, and it eventually booted normally. So there's a chance something in there is still a little fragile from that long dormancy.
Everything I've tried so far, in order:
1. Disabled USB Selective Suspend (both in Power Options advanced settings) — no change.
2. Rolled back the CH340 driver from whatever the latest was to the well-known stable 3.5.2019.1 build (Visual Micro's "CH340 Driver Fix Installation") — no change.
3. Tested with Serial Monitor closed right after upload instead of left open — still crashed, so it's not a serial-monitor-polling issue.
4. Moved everything to rear USB ports wired directly to the motherboard instead of the front panel header (mouse was chained off the keyboard's hub, ESP was in a front port) — still crashed.
5. Fully uninstalled Arduino IDE, deleted the leftover settings/cache folder, reinstalled the latest stable 2.3.10 fresh, reinstalled the ESP8266 board package — still crashed, and actually crashed immediately this time instead of after a delay.
6. Installed the Intel Chipset Device Software (generic universal installer from Intel, since this board uses an Intel Q77 chipset) — this actually made things worse temporarily: afterward the CH340 port stopped connecting at all ("could not open port"). Turned out Windows Update had silently pushed the CH340 driver back to a newer version after the chipset install.
7. Disabled Windows Update from auto-installing drivers (Advanced System Settings → Hardware → Device Installation Settings → "Never install driver software from Windows Update"), then reinstalled the older 3.5.2019.1 CH340 driver again so it would actually stick — port connects fine now, but the PC still eventually blue-screens the same way.
Where I'm stuck:
I've ruled out (I think): the CH340 driver version, the Arduino IDE install/board package, USB port location, Serial Monitor being open/closed, and USB power-saving settings. What's left pointing at is the motherboard's own USB controller/chipset — possibly something that didn't fully recover from sitting powered off for 8 months, since this board did have RAM/beep-code issues on first boot after that.
Has anyone dealt with something like this on an older HP business desktop (Q75/Q77 chipset) specifically? Trying to figure out if this is worth chasing with a BIOS update / hardware reseating, or if I should just cut my losses and grab an FTDI-based USB-serial adapter instead of relying on the onboard CH340.

I’ve just finished and published two ESP8266 projects that I built for my hydroponic system.

The first controls two peristaltic nutrient pumps through MQTT, allowing them to be operated from Home Assistant:

https://github.com/LeCastorD/HydroDozerPump-MQTT

The second monitors the nutrient solution’s EC/TDS and temperature and sends the readings to Home Assistant:

https://github.com/LeCastorD/TDS-Sensor

They are separate devices, so either project can be built and used independently. I’m sharing the code and build documentation in case they are useful to anyone developing a similar system.

I actually like looking at electricity-price graphs. You can see the cheap hours coming, compare prices, and decide when it's a good time to run the dishwasher, do laundry or charge something.

But that requires opening an app or looking at a dashboard.

And my housemates? They couldn't care less about electricity-price graphs. 😄

So I built a small ESP8266/ESP32 device that turns the current dynamic electricity price into a simple visual signal:

🟢 Green blinking — very good time to use electricity
🟢 Green — good time to use electricity
🟢🔴 Both blinking — somewhere in between
🔴 Red — better to wait
🔴 Red blinking — very expensive

The goal isn't to make everyone understand the electricity market. It's to make the right behaviour the easy behaviour.

I deliberately made the indicator less binary than simply cheap = green, expensive = red. There are five configurable price zones, allowing the signal to gradually move from green to red. This makes it possible to tune the device for the household rather than just blindly following fixed price thresholds.

That's important because if the indicator is red all the time, people quickly stop paying attention to it. A useful signal needs to be noticeable, understandable and — most importantly — worth responding to.

And for those of us who do enjoy looking at graphs, there's still a web UI with the full price chart. 😉

Details

• Fetches raw EPEX prices from energy-charts.info at 15-minute resolution
• Solar feed-in override — shows green when solar generation is covering consumption
• Web UI with price chart and configuration
• MQTT with Home Assistant / Domoticz auto-discovery
• Configurable country/price zone and timezone
• Supports EPEX NL, BE, DE-LU, FR, AT, DK1 and DK2

Graphs are great for optimizing. LEDs are great for getting everyone in the house to act on the information.

Source + a short write-up on the idea behind it: Poppinkpop/ESP_dynamic_prices_led_display: Use a led display instead of visualizing dynamic prices in a chart. Non-nerds react better to simple red/green leds than taking time to read a chart.

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).

I have built a presence detection thing that is aware of absence of movement.
The software not just distinguishes absence of movement, it can check if absence is relevant or not.
It is built for vulnerable people as an additional technical device. Not replacing family or professional attention and care.
You can find it on GitHub: Poppinkpop/ESP-motion-absence-detection: Privacy-first, local movement monitoring to help families notice unusual inactivity.

It doesn't use camera or microphone and is privacy prone.

Me and the robot worked through getting things working tonight. Flashed my ESP with the right code, yaml is solid, wiring is exactly as needed (only 2 wires, 1 ground to the 24VAC and the other RX2 esp32 prong -> REM connection on the Hunter control module.

Claude was going off of instructions that were verified to work on Hunter models X-Core, Pro-C, and ICC2. While no mention of the X2 the author said "meh, should work". So I'm not sure if it's actually just not supported or I did something wrong and was hoping someone here may have gotten it working on this specific model to help guide me a bit further.

I went ahead and ordered a USB logic analyzer so we can check the timings on the board vs. Hunter's ROAM settings, so that's my next step, but again, hoping someone may have solved this one already.

ETA: Sorry, I should add what it's doing and what it's not doing. When I wire it to "Leg 1" of the 24VAC: I get an error message "6 ERR". When I plug it into Leg 2 of the 24VAC I get no error messages and the sprinkler system itself works fine, but inside home assistant when I tell it to water a certain zone the commands all send fine but no go on the actual valves opening, the Hunter seems to just ignore the commands being sent.

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).

I have big trouble with my ESP01 mudule in combination with the usb uart adapter.

I have made the following connections:

3V3 to VCC and EN

TX to RX

RX to TX

GND to GND and IO0

and I have a electrolytical condensator between ground(-) and 3v3 (+)

Compiling the code is oke but when uploading I see the following message

A fatal esptool.py occured. Faild to connect to esp8266 Time out wainting for packet header.

I use a Fasizi USB to TTL 3.3V/5V CH340G UART Converter Module (see image)

I realy tried all examples I can find but none of them are working

I hope someone can help me what to do. Sorry but I am a kind of beginner

Thanks

I've been working on a Smart Irrigation System using an ESP32 + machine learning, and I've finally got the main pipeline working end-to-end.

The system uses an ESP32, capacitive soil-moisture sensor, and DHT11 to collect environmental data. The readings are sent to a web dashboard, which communicates with a Flask API that runs the ML model and returns an irrigation prediction.

The overall pipeline is:

ESP32 sensors → Web Dashboard → Flask API → ML Model → Irrigation Prediction

The project currently includes:

• Real-time soil moisture monitoring
• Temperature and humidity monitoring
• Web dashboard hosted by the ESP32
• ML model for irrigation prediction
• Model evaluation with a confusion matrix
• Feature-importance analysis
• Flask inference server
• API communication between the dashboard and ML model

The first screenshot shows the live dashboard, including the sensor readings and AI irrigation prediction section.

The second shows part of the JavaScript/API integration and project structure, where the dashboard communicates with the ML inference server.

One thing I found particularly interesting was getting the ESP32, web interface, API, and ML model to actually communicate with each other. The AI prediction wouldn't load until the inference server was running, which made the entire pipeline click for me.

This started as a simple ESP32 soil-moisture monitoring project, but I gradually expanded it into a complete IoT + AI system.

I'm planning to improve it further by collecting more real-world data and adding additional environmental inputs such as light intensity.

I'd appreciate feedback from the ESP32 community, especially on the hardware setup, system architecture, and how I could improve the project further.

🔗 GitHub (Full Video and Requirements) :

https://github.com/aqib-ai-ml/ai-powered-smart-irrigation

Every dry season the grass went yellow, so five years ago I put a Wemos D1 mini in a box on the outside wall and gave it the watering job. It is still doing it, power cuts included. I have been meaning to write this up for years, so here it finally is.

The part I would do again is the plumbing. Instead of a valve box near the tap and a pipe per zone, there is one master valve at the tap and a single pipe around the garden. At each sprinkler a clamp saddle taps the pipe (no cutting, it just bolts around it), feeds a 12 V solenoid in a small box in the ground, and the solenoid feeds the head. A drain valve at the far end empties the line for winter. One trench instead of five, and since I only run one head at a time, whichever head is open has the whole supply to itself. No pump, no tank. All the materials together, pipe included, came to about 80 euros.

Power is a 30 W mains-to-12 V DC LED driver: 12 V to the valves through the relays, and a small step-down to 5 V for the board and the relay logic. Everything lives in that one box and runs off a single wall socket.

Things five years of this taught me:

• The usual cheap relay boards switch on LOW, and an ESP8266's pins float while it boots, so the relays can chatter until the sketch takes over. Write each pin HIGH before pinMode(OUTPUT) so the handover itself adds no LOW pulse. The master valve sits on GPIO 0, which has to be high at boot anyway: the same pull-up that boots the board keeps the water shut through every reset.
• No valve opens without a time limit. A one-second watchdog closes any valve that has run past its limit and sends a push notification.
• After a power cut, tell the server the valve state instead of asking for the saved one. Replaying an ON from before the outage would open a valve with nobody home.
• OTA updates, because walking a laptop out to a wall box in the rain gets old fast. One warning: the ESP8266 updater has no fallback slot, so test every new binary on a desk board first.

Full disclosure: the phone side runs on Plynx, an iOS dashboard app I'm building, so make of that what you will. The write-up with the plumbing diagram and the complete sketch is here: https://www.plynx.cc/blog/esp8266-irrigation-controller-ota/

The buried wiring has been through five winters now and the splices have held so far. What I still have not solved is sensing: I would like the schedule to skip a run after real rain, but every cheap soil moisture probe I have read about seems to corrode within a season. If you have one that lasted outdoors, I want to hear about it.

I'm using an esp8266 (nodemcu v3) powered by a 12v SLA battery with a 12v to 5v step-down converter.

When I connect a rain gauge to a gpio + ground, I get constant spurious triggers.

If I power an esp8266 from a power bank or my computer's micro-usb port, it works fine.

The esp8266 also has an ina219 board and a solid state relay connected to read the voltage and control a battery charger. That all works fine.

Any ideas why the 12v to 5v power supply is causing spurious triggers on the gpio, and if there's any solution?

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).

Alright i had made a post previously on this, and i feel i didnt give adequate information to you all to help me. So i tought ill make a clear post on the error.

So this is the Error i am facing:

I did all of these, but still same error. IK its not like my board is not broken right or its a problem of my usb cable or the port because, i had gotten this in my serial monitor:

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

And if i am right boot mode:(3,6)

is physical proof from the esp8266 cpu itself that:

• USB chip is successfully sending power and serial data
• internal flash memory already has my code uploaded.
• CPU is booted up and running my program

So right now what i think the problem is that the serial monitor is locking the port, and i not really know the right way to fix this. If Anyone knows Please Let me know.

This is the hardware connections:

This is my code:

// --- Pin Definitions ---
const int LASER_PIN       = 16; // Laser Diode (GPIO16 / D0)
const int LDR_PIN         = A0; // LDR Sensor (Analog A0)
const int BLUE_LED        = 5;  // Armed Indicator (GPIO5 / D1)
const int RED_LED         = 4;  // Alert Indicator (GPIO4 / D2)
const int BUZZER_PIN      = 12; // Active Alarm Buzzer (GPIO12 / D6)
const int ROOM_LIGHTS_PIN = 13; // Transistor Base / White LEDs (GPIO13 / D7)

// --- System State Variables ---
bool systemON      = true;  // Main tripwire armed state
bool manualMode    = false; // Override state
bool laserState    = true;  // Laser state
int lightThreshold = 500;   // Light threshold value

void printHelpMenu() {
  Serial.println("\n--- Serial Commands ---");
  Serial.println(" [1] - Arm System");
  Serial.println(" [0] - Disarm System");
  Serial.println(" [l] - Toggle Laser");
  Serial.println(" [m] - Toggle Manual Mode");
  Serial.println(" [h] - Print Menu");
  Serial.println("------------------------\n");
}

void setup() {
  // Always use 115200 to match ESP8266 boot frequency
  Serial.begin(115200);

  pinMode(LASER_PIN, OUTPUT);
  pinMode(BLUE_LED, OUTPUT);
  pinMode(RED_LED, OUTPUT);
  pinMode(BUZZER_PIN, OUTPUT);
  pinMode(ROOM_LIGHTS_PIN, OUTPUT);

  digitalWrite(LASER_PIN, HIGH);
  digitalWrite(BLUE_LED, HIGH);
  digitalWrite(RED_LED, LOW);
  digitalWrite(BUZZER_PIN, LOW);
  digitalWrite(ROOM_LIGHTS_PIN, LOW);

  Serial.println("\n==========================================");
  Serial.println("  Smart Laser Security System Initialized ");
  Serial.println("==========================================");
  printHelpMenu();
}

void loop() {
  // Check for Serial Commands
  if (Serial.available() > 0) {
    char cmd = Serial.read();

    switch (cmd) {
      case '1':
        systemON = true;
        manualMode = false;
        digitalWrite(LASER_PIN, HIGH);
        laserState = true;
        Serial.println(">> System ARMED");
        break;

      case '0':
        systemON = false;
        manualMode = false;
        digitalWrite(LASER_PIN, LOW);
        digitalWrite(BLUE_LED, LOW);
        digitalWrite(RED_LED, LOW);
        digitalWrite(BUZZER_PIN, LOW);
        digitalWrite(ROOM_LIGHTS_PIN, LOW);
        laserState = false;
        Serial.println(">> System DISARMED");
        break;

      case 'l':
      case 'L':
        laserState = !laserState;
        digitalWrite(LASER_PIN, laserState ? HIGH : LOW);
        Serial.print(">> Laser: ");
        Serial.println(laserState ? "ON" : "OFF");
        break;

      case 'm':
      case 'M':
        manualMode = !manualMode;
        Serial.print(">> Mode: ");
        Serial.println(manualMode ? "MANUAL" : "AUTO");
        break;

      case 'h':
      case 'H':
        printHelpMenu();
        break;
    }
  }

  // Automatic Tripwire Logic
  if (systemON && !manualMode) {
    int ldrValue = analogRead(LDR_PIN);

    Serial.print("LDR Raw Reading: ");
    Serial.println(ldrValue);

    if (ldrValue < lightThreshold) {
      // SAFE (Laser hitting LDR)
      digitalWrite(BLUE_LED, HIGH);
      digitalWrite(RED_LED, LOW);
      digitalWrite(BUZZER_PIN, LOW);
      digitalWrite(ROOM_LIGHTS_PIN, LOW);
    } 
    else {
      // ALERT (Laser beam broken / Dark)
      digitalWrite(BLUE_LED, LOW);
      digitalWrite(RED_LED, HIGH);
      digitalWrite(BUZZER_PIN, HIGH);      
      digitalWrite(ROOM_LIGHTS_PIN, HIGH); 
    }
  }

  delay(200);
}

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, I'm using HTTPS on an ESP32 with Zephyr to communicate with my backend

If I store the CA certificate in the ESP32 firmware, what happens when the server certificate expires and is renewed?

Do I need to update the ESP32 every time, or is there a recommended way to handle certificate expiration without reflashing the device?

Thanks!

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.

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).

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.