ESP32 board crashing, but keeps accepting ping

ESPHome
1

A while ago, I saw this:

I decided to install this. I bought the sensors, and compiled this with ESPHome 2026.5.3:

esphome:
  name: bedsensor-esp32

esp32:
  board: az-delivery-devkit-v4
  framework:
    type: esp-idf
    advanced:
      minimum_chip_revision: "3.1"
      sram1_as_iram: true

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  #password: ""
  encryption:
    key: "[REDACTED]"

ota:
  - platform: esphome
    password: ""

wifi:
  ssid: "[REDACTED]"
  password: "[REDACTED]"

  manual_ip:
    static_ip: 192.168.1.137
    gateway: 192.168.1.1
    subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Bedsensor Fallback Hotspot"
    password: "[REDACTED]"

captive_portal:

# Inspiratie: https://www.youtube.com/watch?v=E9xRV_8QHRo

time:
  - platform: homeassistant
    id: tijd
sensor:
  - platform: uptime
    type: timestamp
    name: laatste_herstart
    id: laatste_herstart
switch:
  - platform: restart
    name: opnieuw_opstarten
    id: opnieuw_opstarten
binary_sensor:
  - platform: gpio
    pin:
      number: 26 # pin GPIO26
      inverted: true
      mode:
        input: true
        pullup: true
    name: bed_DBE
    device_class: occupancy
    filters:
      - delayed_on: 5s
      - delayed_off: 30s

  - platform: gpio
    pin:
      number: 27 # pin GPIO27
      inverted: true
      mode:
        input: true
        pullup: true
    name: bed_CLN
    device_class: occupancy
    filters:
      - delayed_on: 5s
      - delayed_off: 30s

For some reason, the device keeps crashing, so that I can't connect to it anymore via esphome (or Home Assistant - be it via openHAB's binding). However! I can still ping the device...

I thought I'd try Claude, and it suggested to add these sensors:

  - platform: template
    name: "Vrij geheugen"
    lambda: 'return heap_caps_get_free_size(MALLOC_CAP_INTERNAL);'
    unit_of_measurement: "B"
    update_interval: 60s
  - platform: wifi_signal
    name: "WiFi signaal"
    update_interval: 60s

... and record the logs, using these commands:

tmux new -s bedsensor_logs
esphome logs /opt/esphome/yaml-bestanden/bedsensor.yaml | tee ~/bedsensor_log.txt

After some time, the device indeed crashed (more or less). I gave Claude these logs:

(venv) erik@MinipcLG2:/var/log/openhab$ cat events.log | grep -i bedsensor
2026-06-14 09:45:49.429 [INFO ] [ab.event.ThingStatusInfoChangedEvent - 429       ] - Thing 'esphome:device:bedsensor' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
2026-06-14 09:45:51.110 [INFO ] [ab.event.ThingStatusInfoChangedEvent - 429       ] - Thing 'esphome:device:bedsensor' changed from INITIALIZING to ONLINE
2026-06-14 09:45:51.588 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_laatste_herstart' changed from NULL to 2026-06-14T09:34:24.000+0200 (source: org.openhab.core.thing$esphome:device:bedsensor:laatste_herstart)
2026-06-14 19:54:13.442 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_Vrij_geheugen' changed from NULL to 249468 B (source: org.openhab.core.thing$esphome:device:bedsensor:vrij_geheugen)
2026-06-14 19:54:22.058 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_WiFi_signaal' changed from NULL to 3.162277660168371E-9 W (source: org.openhab.core.thing$esphome:device:bedsensor:wifi_signaal)
2026-06-14 22:02:21.108 [INFO ] [ab.event.ThingStatusInfoChangedEvent - 429       ] - Thing 'esphome:device:bedsensor' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): ESPHome did not respond to ping requests. 4 pings sent with 10 s delay. Will reconnect in 15 seconds
2026-06-14 22:02:21.109 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'bedsensor_DBE_switch' changed from OFF to UNDEF (source: org.openhab.core.thing$esphome:device:bedsensor:bed_dbe)
2026-06-14 22:02:21.109 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'bedsensor_CLN_switch' changed from OFF to UNDEF (source: org.openhab.core.thing$esphome:device:bedsensor:bed_cln)
2026-06-14 22:02:21.110 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_laatste_herstart' changed from 2026-06-14T09:34:24.000+0200 to UNDEF (source: org.openhab.core.thing$esphome:device:bedsensor:laatste_herstart)
2026-06-14 22:02:21.110 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_Vrij_geheugen' changed from 249468 B to UNDEF (source: org.openhab.core.thing$esphome:device:bedsensor:vrij_geheugen)
2026-06-14 22:02:21.110 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_WiFi_signaal' changed from 3.162277660168371E-9 W to UNDEF (source: org.openhab.core.thing$esphome:device:bedsensor:wifi_signaal)
2026-06-14 22:02:21.111 [INFO ] [openhab.event.ItemStateChangedEvent  - 429       ] - Item 'Bedsensor_opnieuw_opstarten' changed from OFF to UNDEF (source: org.openhab.core.thing$esphome:device:bedsensor:opnieuw_opstarten)
2026-06-14 22:03:36.141 [INFO ] [ab.event.ThingStatusInfoChangedEvent - 429       ] - Thing 'esphome:device:bedsensor' changed from OFFLINE (COMMUNICATION_ERROR): ESPHome did not respond to ping requests. 4 pings sent with 10 s delay. Will reconnect in 15 seconds to OFFLINE (COMMUNICATION_ERROR): Connection attempt timed out. Will reconnect in 26 seconds
2026-06-14 22:05:02.145 [INFO ] [ab.event.ThingStatusInfoChangedEvent - 429       ] - Thing 'esphome:device:bedsensor' changed from OFFLINE (COMMUNICATION_ERROR): Connection attempt timed out. Will reconnect in 26 seconds to OFFLINE (COMMUNICATION_ERROR): Connection attempt timed out. Will reconnect in 47 seconds
2026-06-14 22:06:49.151 [INFO ] [ab.event.ThingStatusInfoChangedEvent - 429       ] - Thing 'esphome:device:bedsensor' changed from OFFLINE (COMMUNICATION_ERROR): Connection attempt timed out. Will reconnect in 47 seconds to OFFLINE (COMMUNICATION_ERROR): Connection attempt timed out. Will reconnect in 116 seconds

(and so on)

(venv) erik@MinipcLG2:/var/log/openhab$ tail -100 /opt/esphome/yaml-bestanden/bedsensor_log.txt
[19:53:51.703][C][wifi:1248]:   Subnet: 255.255.255.0
[19:53:51.703][C][wifi:1248]:   Gateway: 192.168.1.1
[19:53:51.703][C][wifi:1248]:   DNS1: 0.0.0.0
[19:53:51.703][C][wifi:1248]:   DNS2: 0.0.0.0
[19:53:51.722][C][esphome.ota:097]: Over-The-Air updates:
[19:53:51.722][C][esphome.ota:097]:   Address: 192.168.1.137:3232
[19:53:51.722][C][esphome.ota:097]:   Version: 2
[19:53:51.737][C][safe_mode:058]: Safe Mode:
[19:53:51.737][C][safe_mode:058]:   Successful after: 60s
[19:53:51.737][C][safe_mode:058]:   Invoke after: 10 attempts
[19:53:51.737][C][safe_mode:058]:   Duration: 300s
[19:53:51.742][C][safe_mode:079]:   Bootloader rollback: supported
[19:53:51.765][C][web_server.ota:256]: Web Server OTA
[19:53:51.787][C][api:238]: Server:
[19:53:51.787][C][api:238]:   Address: 192.168.1.137:6053
[19:53:51.787][C][api:238]:   Listen backlog: 4
[19:53:51.787][C][api:238]:   Max connections: 5
[19:53:51.793][C][api:245]:   Noise encryption: YES
[19:53:51.809][C][wifi_signal.sensor:017]: WiFi Signal 'WiFi signaal'
[19:53:51.809][C][wifi_signal.sensor:017]:   State Class: 'measurement'
[19:53:51.809][C][wifi_signal.sensor:017]:   Unit of Measurement: 'dBm'
[19:53:51.809][C][wifi_signal.sensor:017]:   Accuracy Decimals: 0
[19:53:51.810][C][wifi_signal.sensor:232]:   Device Class: 'signal_strength'
[19:53:51.829][C][mdns:230]: mDNS:
[19:53:51.829][C][mdns:230]:   Hostname: bedsensor-esp32
[19:53:54.291][D][api.connection:2461]: ESPHome Logs 2026.5.3 (192.168.1.9): disconnected
[21:04:37.372][D][api:223]: Accept 192.168.1.9
[21:04:37.481][D][api.connection:2461]: ESPHome Logs 2026.5.3 (192.168.1.9): connected
[21:04:37.529][I][app:151]: ESPHome version 2026.5.3 compiled on 2026-06-14 08:47:17 +0200
[21:04:37.531][I][app:158]: ESP32 Chip: ESP32 rev1.0, 2 core(s)
[21:04:37.536][C][logger:219]: Logger:
[21:04:37.536][C][logger:219]:   Max Level: DEBUG
[21:04:37.536][C][logger:219]:   Initial Level: DEBUG
[21:04:37.559][C][logger:226]:   Log Baud Rate: 115200
[21:04:37.559][C][logger:226]:   Hardware UART: UART0
[21:04:37.566][C][logger:235]:   Task Log Buffer Size: 768 bytes
[21:04:37.570][C][uptime.sensor:017]: Uptime Sensor 'laatste_herstart'
[21:04:37.570][C][uptime.sensor:017]:   State Class: ''
[21:04:37.570][C][uptime.sensor:017]:   Unit of Measurement: ''
[21:04:37.570][C][uptime.sensor:017]:   Accuracy Decimals: 0
[21:04:37.574][C][uptime.sensor:232]:   Device Class: 'timestamp'
[21:04:37.578][C][uptime.sensor:223]:   Icon: 'mdi:timer-outline'
[21:04:37.581][C][uptime.sensor:032]:   Type: Timestamp
[21:04:37.607][C][template.sensor:017]: Template Sensor 'Vrij geheugen'
[21:04:37.607][C][template.sensor:017]:   State Class: ''
[21:04:37.607][C][template.sensor:017]:   Unit of Measurement: 'B'
[21:04:37.607][C][template.sensor:017]:   Accuracy Decimals: 1
[21:04:37.611][C][template.sensor:451]:   Update Interval: 60.0s
[21:04:37.634][C][gpio.binary_sensor:016]: GPIO Binary Sensor 'bed_DBE'
[21:04:37.639][C][gpio.binary_sensor:232]:   Device Class: 'occupancy'
[21:04:37.644][C][gpio.binary_sensor:152]:   Pin: GPIO26
[21:04:37.648][C][gpio.binary_sensor:061]:   Mode: interrupt
[21:04:37.659][C][gpio.binary_sensor:063]:   Interrupt Type: ANY_EDGE
[21:04:37.669][C][gpio.binary_sensor:016]: GPIO Binary Sensor 'bed_CLN'
[21:04:37.680][C][gpio.binary_sensor:232]:   Device Class: 'occupancy'
[21:04:37.683][C][gpio.binary_sensor:152]:   Pin: GPIO27
[21:04:37.684][C][gpio.binary_sensor:061]:   Mode: interrupt
[21:04:37.684][C][gpio.binary_sensor:063]:   Interrupt Type: ANY_EDGE
[21:04:37.699][C][homeassistant.time:009]: Home Assistant Time
[21:04:37.703][C][time:049]: Timezone: UTC+1:00 (DST UTC+2:00)
[21:04:37.723][C][time:055]: Current time: 2026-06-14 21:04:37
[21:04:37.797][C][restart:088]: Restart Switch 'opnieuw_opstarten'
[21:04:37.797][C][restart:088]:   Restore Mode: always OFF
[21:04:37.797][C][restart:223]:   Icon: 'mdi:restart'
[21:04:37.797][C][captive_portal:133]: Captive Portal:
[21:04:37.797][C][wifi:1526]: WiFi:
[21:04:37.797][C][wifi:1526]:   Local MAC: [REDACTED]
[21:04:37.797][C][wifi:1526]:   Connected: YES
[21:04:37.797][C][wifi:1237]:   IP Address: 192.168.1.137
[21:04:37.798][C][wifi:1248]:   SSID: [REDACTED]
[21:04:37.798][C][wifi:1248]:   BSSID: [REDACTED]
[21:04:37.798][C][wifi:1248]:   Hostname: 'bedsensor-esp32'
[21:04:37.798][C][wifi:1248]:   Signal strength: -56 dB ▂▄▆█
[21:04:37.798][C][wifi:1248]:   Channel: 1
[21:04:37.798][C][wifi:1248]:   Subnet: 255.255.255.0
[21:04:37.798][C][wifi:1248]:   Gateway: 192.168.1.1
[21:04:37.798][C][wifi:1248]:   DNS1: 0.0.0.0
[21:04:37.798][C][wifi:1248]:   DNS2: 0.0.0.0
[21:04:37.803][C][esphome.ota:097]: Over-The-Air updates:
[21:04:37.803][C][esphome.ota:097]:   Address: 192.168.1.137:3232
[21:04:37.803][C][esphome.ota:097]:   Version: 2
[21:04:37.832][C][safe_mode:058]: Safe Mode:
[21:04:37.832][C][safe_mode:058]:   Successful after: 60s
[21:04:37.832][C][safe_mode:058]:   Invoke after: 10 attempts
[21:04:37.832][C][safe_mode:058]:   Duration: 300s
[21:04:37.837][C][safe_mode:079]:   Bootloader rollback: supported
[21:04:37.837][C][web_server.ota:256]: Web Server OTA
[21:04:37.861][C][api:238]: Server:
[21:04:37.861][C][api:238]:   Address: 192.168.1.137:6053
[21:04:37.861][C][api:238]:   Listen backlog: 4
[21:04:37.861][C][api:238]:   Max connections: 5
[21:04:37.875][C][api:245]:   Noise encryption: YES
[21:04:37.878][C][wifi_signal.sensor:017]: WiFi Signal 'WiFi signaal'
[21:04:37.878][C][wifi_signal.sensor:017]:   State Class: 'measurement'
[21:04:37.878][C][wifi_signal.sensor:017]:   Unit of Measurement: 'dBm'
[21:04:37.878][C][wifi_signal.sensor:017]:   Accuracy Decimals: 0
[21:04:37.879][C][wifi_signal.sensor:232]:   Device Class: 'signal_strength'
[21:04:37.904][C][mdns:230]: mDNS:
[21:04:37.904][C][mdns:230]:   Hostname: bedsensor-esp32
[21:06:00.404][D][api.connection:2461]: ESPHome Logs 2026.5.3 (192.168.1.9): disconnected
(venv) erik@MinipcLG2:/var/log/openhab$ ls -lh /opt/esphome/yaml-bestanden/bedsensor_log.txt
date
-rw-rw-r-- 1 erik erik 17K jun 14 21:06 /opt/esphome/yaml-bestanden/bedsensor_log.txt
ma 15 jun 2026 14:46:12 CEST
(venv) erik@MinipcLG2:/var/log/openhab$

After tmux attach -t bedsensor_logs, the screen shows this:

[21:04:37.797][C][wifi:1237]:   IP Address: 192.168.1.137
[21:04:37.798][C][wifi:1248]:   SSID: '49x27-Dn'
[21:04:37.798][C][wifi:1248]:   BSSID: D8:B3:70:55:0A:BE
[21:04:37.798][C][wifi:1248]:   Hostname: 'bedsensor-esp32'
[21:04:37.798][C][wifi:1248]:   Signal strength: -56 dB ▂▄▆█
[21:04:37.798][C][wifi:1248]:   Channel: 1
[21:04:37.798][C][wifi:1248]:   Subnet: 255.255.255.0
[21:04:37.798][C][wifi:1248]:   Gateway: 192.168.1.1
[21:04:37.798][C][wifi:1248]:   DNS1: 0.0.0.0
[21:04:37.798][C][wifi:1248]:   DNS2: 0.0.0.0
[21:04:37.803][C][esphome.ota:097]: Over-The-Air updates:
[21:04:37.803][C][esphome.ota:097]:   Address: 192.168.1.137:3232
[21:04:37.803][C][esphome.ota:097]:   Version: 2
[21:04:37.832][C][safe_mode:058]: Safe Mode:
[21:04:37.832][C][safe_mode:058]:   Successful after: 60s
[21:04:37.832][C][safe_mode:058]:   Invoke after: 10 attempts
[21:04:37.832][C][safe_mode:058]:   Duration: 300s
[21:04:37.837][C][safe_mode:079]:   Bootloader rollback: supported
[21:04:37.837][C][web_server.ota:256]: Web Server OTA
[21:04:37.861][C][api:238]: Server:
[21:04:37.861][C][api:238]:   Address: 192.168.1.137:6053
[21:04:37.861][C][api:238]:   Listen backlog: 4
[21:04:37.861][C][api:238]:   Max connections: 5
[21:04:37.875][C][api:245]:   Noise encryption: YES
[21:04:37.878][C][wifi_signal.sensor:017]: WiFi Signal 'WiFi signaal'
[21:04:37.878][C][wifi_signal.sensor:017]:   State Class: 'measurement'
[21:04:37.878][C][wifi_signal.sensor:017]:   Unit of Measurement: 'dBm'
[21:04:37.878][C][wifi_signal.sensor:017]:   Accuracy Decimals: 0
[21:04:37.879][C][wifi_signal.sensor:232]:   Device Class: 'signal_strength'
[21:04:37.904][C][mdns:230]: mDNS:
[21:04:37.904][C][mdns:230]:   Hostname: bedsensor-esp32
[21:06:00.404][D][api.connection:2461]: ESPHome Logs 2026.5.3 (192.168.1.9): disconnected
INFO Processing unexpected disconnect from ESPHome API for bedsensor-esp32 @ 192.168.1.137
WARNING Disconnected from API
INFO Successfully resolved bedsensor-esp32 @ 192.168.1.137 in 0.002s
INFO Successfully connected to bedsensor-esp32 @ 192.168.1.137 in 0.064s
WARNING Can't connect to ESPHome API for bedsensor-esp32 @ 192.168.1.137: Handshake timed out after 60.0s (TimeoutAPIError)
INFO Trying to connect to bedsensor-esp32 @ 192.168.1.137 in the background
INFO Successfully connected to bedsensor-esp32 @ 192.168.1.137 in 0.072s

[bedsensor0:python*                                                                                                              "MinipcLG2" 14:51 15-jun-2

(venv) erik@MinipcLG2:/var/log/openhab$ grep -i "geheugen\|wifi signaal" /opt/esphome/yaml-bestanden/bedsensor_log.txt
[09:38:42.031][C][template.sensor:017]: Template Sensor 'Vrij geheugen'
[09:38:42.263][C][wifi_signal.sensor:017]: WiFi Signal 'WiFi signaal'
[09:38:46.603][S][sensor]: 'WiFi signaal' >> -52 dBm
[09:38:48.807][S][sensor]: 'Vrij geheugen' >> 249628.0 B
[09:39:46.584][S][sensor]: 'WiFi signaal' >> -54 dBm
[09:39:48.491][S][sensor]: 'Vrij geheugen' >> 249560.0 B
[09:40:46.598][S][sensor]: 'WiFi signaal' >> -55 dBm
[09:40:48.505][S][sensor]: 'Vrij geheugen' >> 249560.0 B
[09:41:46.601][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:41:48.501][S][sensor]: 'Vrij geheugen' >> 249560.0 B
[09:42:46.586][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:42:48.498][S][sensor]: 'Vrij geheugen' >> 251120.0 B
[09:43:46.592][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:43:48.500][S][sensor]: 'Vrij geheugen' >> 251120.0 B
[09:44:46.577][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:44:48.500][S][sensor]: 'Vrij geheugen' >> 251124.0 B
[09:45:46.584][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:45:48.490][S][sensor]: 'Vrij geheugen' >> 251124.0 B
[09:46:46.577][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:46:48.485][S][sensor]: 'Vrij geheugen' >> 249552.0 B
[09:47:46.594][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:47:48.507][S][sensor]: 'Vrij geheugen' >> 247644.0 B
[09:48:46.589][S][sensor]: 'WiFi signaal' >> -59 dBm
[09:48:48.498][S][sensor]: 'Vrij geheugen' >> 247868.0 B
[09:49:46.580][S][sensor]: 'WiFi signaal' >> -58 dBm
[09:49:48.494][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:50:46.577][S][sensor]: 'WiFi signaal' >> -58 dBm
[09:50:48.485][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:51:46.574][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:51:48.485][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:52:47.916][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:52:48.480][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:53:46.575][S][sensor]: 'WiFi signaal' >> -57 dBm
[09:53:48.485][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:54:46.572][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:54:48.485][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:55:46.573][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:55:48.482][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:56:46.571][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:56:48.492][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:57:46.579][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:57:48.487][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:58:46.575][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:58:48.488][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[09:59:46.571][S][sensor]: 'WiFi signaal' >> -56 dBm
[09:59:48.483][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[10:00:46.577][S][sensor]: 'WiFi signaal' >> -56 dBm
[10:00:48.482][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[10:01:46.568][S][sensor]: 'WiFi signaal' >> -56 dBm
[10:01:48.480][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[10:02:46.565][S][sensor]: 'WiFi signaal' >> -56 dBm
[10:02:48.477][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[10:03:46.564][S][sensor]: 'WiFi signaal' >> -56 dBm
[10:03:48.476][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[10:04:44.701][S][sensor]: 'WiFi signaal' >> -55 dBm
[10:04:44.702][S][sensor]: 'Vrij geheugen' >> 249480.0 B
[10:42:37.177][S][sensor]: 'Vrij geheugen' >> 249468.0 B
[10:42:37.177][S][sensor]: 'WiFi signaal' >> -55 dBm
[19:53:51.535][C][template.sensor:017]: Template Sensor 'Vrij geheugen'
[19:53:51.809][C][wifi_signal.sensor:017]: WiFi Signal 'WiFi signaal'
[21:04:37.607][C][template.sensor:017]: Template Sensor 'Vrij geheugen'
[21:04:37.878][C][wifi_signal.sensor:017]: WiFi Signal 'WiFi signaal'
(venv) erik@MinipcLG2:/var/log/openhab$ grep -iE "error|warn|fail|disconnect|reconnect|abort|panic" /opt/esphome/yaml-bestanden/bedsensor_log.txt
[09:42:08.942][D][api.connection:2461]: openHAB (192.168.1.9): disconnected
[09:42:08.951][W][api.connection:2467]: openHAB (192.168.1.9): Reading failed CONNECTION_CLOSED errno=128
[19:53:54.291][D][api.connection:2461]: ESPHome Logs 2026.5.3 (192.168.1.9): disconnected
[21:06:00.404][D][api.connection:2461]: ESPHome Logs 2026.5.3 (192.168.1.9): disconnected
(venv) erik@MinipcLG2:/var/log/openhab$

Claude concluded this:

This is a great catch — and it's actually a very clean, reproducible pattern. Here's what the data shows:
The scheduler stops dead, ~68 minutes after boot.
Looking at the [S][sensor] ("Sending state") lines — these are the actual periodic update_interval callbacks firing — they run like clockwork every 60s from 09:38:46 to 10:42:37 (that's 09:34:24 boot + ~68 minutes). After 10:42:37, there is not a single [S][sensor] line for the rest of the entire log file. No more heap readings, no more WiFi signal readings, nothing. The scheduler that drives update_interval callbacks simply stopped firing.
But the network/API didn't die immediately — it degraded in stages over the following ~11 hours:

10:42 → 19:53 (~9 hours): periodic sensors dead, but presumably WiFi/API still basically fine (we have no log activity in this window since nothing was connected)
19:53 & 21:04: esphome logs could still connect and get a full, fast, correct config dump (everything reported normal: WiFi connected, -56dB, IP correct)
21:06 onward: reconnect attempts now TCP-connect instantly but the Noise encryption handshake times out after 60s — the API task accepts the connection but can no longer complete the handshake
Eventually (by the time you ran nmap): even the TCP SYN gets no response at all — only ICMP/ARP (handled by the WiFi driver/lwIP at a lower level) still works

So this looks like a progressive lockup of FreeRTOS tasks, starting with the scheduler (App.scheduler, ~68 min in), then later the API connection-handling task, eventually leaving only the lowest-level network driver responsive. The flat heap value (249468.0 B) after the freeze is not evidence of "no leak" — that sensor itself stopped updating at the same moment everything else did, so we have zero visibility into heap after 10:42.

It's also worth a quick search of the ESPHome GitHub issues for "scheduler stops" combined with esp-idf 5.5.4 or homeassistant time — this smells like a known regression rather than something specific to your hardware.

Sorry for all the AI junk, but I thought to try the machine before harassing real humans.

But I think I'm at that point now... Does anyone have any idea why my ESP32 keeps failing?

Thanks in advance for anyone's help!

2

Did you try hooking up the ESP to your PC via USB?
Actual crashes will show on the serial console, but not on the network one.

3

Remove those options. I don't understand how would that work since your log shows:

4

Removing this cleared the issue, and the logs didn't instruct me to put it in again. I don't know why it was there, if the logs didn't tell me to put it there.

Maybe it was a leftover of the yaml file I copied to make this one. Sloppy...

Thanks for the help!

5

AI tends to put things in and leave things out. So you need to put notes into the yaml config for devices using # sign. Double check by having the AI check for the proper versions and hardware level, you do need to let AI know this or it assumes always (Specifics count!!)

6

Then no-one knows.
Interestingly, according to docs, flashing your code with that parameter should fail.
Someone knows why it didn't?

7

Pointers to unknown locations is a basic coding error that goes back to the earliest days of computing. You are not alone, not by a long shot! Even compilers and CPU microcode have subtle pointer bugs that are being found, many years after they have been used by millions, often by vendors unleashing AI analysis tools on their code to find them before state based attackers and skript kiddies do

Sloppy, or just AI slop?

You specifically told the compiler in your code to use PSRAM that isn't actually there on your chip. It faithfully did what is was told and generated code that crashed when it ran and attempted to use that memory location. Boom!

Just because your code has no syntax errors doesn't mean it has no logic errors.

The above posts should be useful instructions for the errant AI bot that may have been implicitly trusted, but hopelessly wrong. Sadly, AI Slop is too common and poisoning it for those that cannot or refuse to read vendor documentation or cut-and-paste code without understanding the implications, or why the code exists in the manner it has been handed to you as the final solution - it isn't. Most AI engines are actually LLM reproducers, tidying up what they have slurped up off the internet, carefully slurping up code from forums like this of code that has problems, but fails to document the actual fixes, correcting spelling and grammatical errors, and then confidently handing it back to you, completely wrong, but so easy to paste into your code. They also increasingly charge you for the privilege to give you wrong information and ask you to guide them when you complain it is wrong. You don't get paid or get credit for your guidance to teach it what it got wrong.

The AI backlash tidal wave has started. It will be brutal.

If you didn't use AI, it is a learning lesson on why you should stand on the shoulders of giants, but look how far you have to fall if you jump off. Know what and why your code is doing, ALWAYS.

8

I didn't use Claude to generate the YAML file. I've got other ESP32's, some of which do actually have that 3.1 chip. But when I 'install' a new ESP32, I copy an existing YAML file.

9

Interesting.