espectre

Long calibration usually means the effective CSI packet rate is far below the configured traffic_generator_rate. The default DNS-based traffic generator may be ignored or rate-limited by some routers. Switch the traffic generator to ping mode in your YAML config, then recompile and flash:

espectre:
  traffic_generator_rate: 100
  traffic_generator_mode: ping

After rebooting, check that the CSI packet rate is close to 100 packets/s; calibration should complete much faster.

Upgrade ESPectre to 3.0.0-rc1 or newer, which fixes the constructor initialization order and %u/uint32_t logging format warnings. In your YAML, pin the external component to the release tag, for example:

external_components:
  - source:
      type: git
      url: https://github.com/francescopace/espectre
      ref: 3.0.0-rc1
    components: [ espectre ]
    refresh: 300s

Then reinstall the ESPHome firmware. These warnings are generated by ESPectre, not NSPanel-Easy; in 2.8.x they are non-fatal and compilation, OTA installation, and motion detection can still work.

The reset is caused by synchronous MQTT sends blocking the ESPHome main loop while CSI processing, BLE, and logging are also running. On ESP-IDF, enable asynchronous MQTT sending and reduce MQTT overhead by disabling discovery and MQTT log forwarding:

mqtt:
  broker: broker.hivemq.com
  port: 1883
  idf_send_async: true
  discovery: false
  log_topic: None

Rebuild and flash with:

esphome run espectre-s3.yaml

idf_send_async: true moves MQTT transmission into a separate task so it no longer blocks loopTask. Disabling discovery and log_topic reduces processing and network traffic. This configuration was confirmed to resolve the watchdog reset while keeping Wi-Fi, CSI, calibration, motion detection, serial logging, the Home Assistant API, and MQTT publishing working.

Internet connectivity is not required; CSI collection needs local Wi-Fi traffic between devices on the same LAN. Since the ESP32-S3 associates successfully but CSI remains 0 after traffic-generator retries, generate external traffic toward the board from another PC or phone on the same network. Use the IP shown in the log, for example:

Linux/macOS:
ping 192.168.1.100

Windows:
ping -t 192.168.1.100

Let it run for 30–60 seconds while Micro-ESPectre starts. Also verify the router is using a compatible mode such as 802.11n/b/g with HT20. If CSI packets appear while pinging, the problem is likely the AP/router not handling the internal traffic-generation/CSI-trigger path; continue using external LAN traffic or test with another router. Firmware compatibility is less likely because the S3 chip is detected and Wi-Fi connects successfully.

Try reducing the traffic-generator rate and switching from ping to dns mode, then allow extra time for calibration; calibration can produce no logs or sensor updates initially:

espectre:
  id: espectre_csi
  traffic_generator_mode: dns
  traffic_generator_rate: 50

Keep your existing detection_algorithm setting. Re-flash and wait beyond the usual startup period before checking sensor.movement_score and binary_sensor.motion_detected.

If it still publishes nothing, the likely cause is AP incompatibility: the router must return usable 802.11n HT20 frames to the ESP32-S3. Verify the router is set to a compatible 2.4 GHz 802.11n/b/g/n mode rather than an incompatible Wi-Fi 6/AX or n-only configuration, and test against another access point if possible.