Replies: 4 comments 10 replies
-
|
ESP located in a room on the first floor, AP in the same room at about 3 meters, no one else on the same floor. The only presence is myself on the ground floor at a distance of about 8–9 meters. No movement in the room. Periodically, movement is detected for a variable period of a few minutes and then disappears again. What does it depend on?
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @studiobts, Thank you so much for sharing this detailed analysis! It's incredibly valuable to have real-world test cases like this to improve ESPectre. 🙏 Initial ObservationsLooking at your logs, I noticed something interesting. The graph shows a very consistent plateau around value 5 during the false positive periods. This regularity suggests it might not be random noise, but rather electromagnetic interference from an electrical appliance nearby. Common culprits include:
Request: Extended Log SampleCould you please capture and attach a longer log file that includes:
This would help me correlate the packet rate drops with the interference pattern. You can attach a Key QuestionWhen real movement occurs in the room, does the movement value go above or below 5?
Advanced Filtering OptionsESPectre includes experimental filters that might help with this type of interference: espectre:
# Hampel filter - removes outlier spikes
hampel_enabled: true
hampel_window: 7 # 3-11
hampel_threshold: 4.0 # 1.0-10.0
# Low-pass filter - smooths high frequencies (human movements are tipically 2-8Hz)
lowpass_enabled: true
lowpass_cutoff: 11.0 # 5.0-20.0 Hz
# Normalization - different esp32 boards can produce different values of CSI
normalization_enabled: true
normalization_target: 28.0About the Traffic Generator ErrorsYou can safely ignore the During the first ~10 seconds after boot, ESPectre runs an Auto-Calibration phase (you can see "Auto-Calibration Starting" in the logs). During this phase, no data is sent to Home Assistant - the system is collecting CSI samples to select the best subcarriers for your environment. The errors occur because there's a brief packet queue buildup right after the calibration phase completes and before normal operation resumes. These are just temporary warnings that don't affect functionality. I need to handle this transition more gracefully in the code - it's on my TODO list! Please let me know what values you see during real movement, and share an extended log if possible. This will help me understand the interference pattern and suggest the best configuration for your environment! |
Beta Was this translation helpful? Give feedback.
-
|
I would be very happy to run further tests, but I have flashed the board again and it seems as if the system freezes. There are no logs from the packet generator, or when there are, the generated packets are often very few, or none are generated for several seconds. In this log, based on the timestamps, you can observe that:
For completeness, I am attaching the full configuration generated by ESPHome. esphome:
name: espectre-test-1
friendly_name: 'ESPectre Test #1'
comment: ESP32 Mini D1
compile_process_limit: 1
min_version: 2025.12.0
build_path: build/espectre-test-1
platformio_options: {}
environment_variables: {}
includes: []
includes_c: []
libraries: []
name_add_mac_suffix: false
debug_scheduler: false
areas: []
devices: []
esp32:
board: esp32dev
framework:
type: esp-idf
version: 5.5.1
sdkconfig_options:
CONFIG_PM_ENABLE: n
CONFIG_ESP_WIFI_STA_DISCONNECTED_PM_ENABLE: n
CONFIG_ESP_WIFI_CSI_ENABLED: y
log_level: ERROR
advanced:
compiler_optimization: SIZE
enable_idf_experimental_features: false
enable_lwip_assert: true
ignore_efuse_custom_mac: false
ignore_efuse_mac_crc: false
enable_lwip_mdns_queries: true
enable_lwip_bridge_interface: false
enable_lwip_tcpip_core_locking: true
enable_lwip_check_thread_safety: true
disable_libc_locks_in_iram: true
disable_vfs_support_termios: true
disable_vfs_support_select: true
disable_vfs_support_dir: true
freertos_in_iram: false
ringbuf_in_iram: false
execute_from_psram: false
loop_task_stack_size: 8192
components: []
source: pioarduino/framework-espidf@https://github.com/pioarduino/esp-idf/releases/download/v5.5.1/esp-idf-v5.5.1.tar.xz
platform_version: https://github.com/pioarduino/platform-espressif32/releases/download/55.03.31-2/platform-espressif32.zip
flash_size: 4MB
variant: ESP32
cpu_frequency: 160MHZ
logger:
level: DEBUG
baud_rate: 115200
tx_buffer_size: 512
deassert_rts_dtr: false
task_log_buffer_size: 768
hardware_uart: UART0
logs: {}
runtime_tag_levels: false
api:
reboot_timeout: 15min
encryption:
key: REDACTED
port: 6053
password: ''
batch_delay: 100ms
custom_services: false
homeassistant_services: false
homeassistant_states: false
listen_backlog: 4
max_connections: 8
max_send_queue: 8
ota:
- platform: esphome
password: REDACTED
version: 2
port: 3232
switch:
- platform: restart
id: board_restart
name: Board Reboot
disabled_by_default: false
restore_mode: ALWAYS_OFF
entity_category: config
icon: mdi:restart
wifi:
manual_ip:
static_ip: 10.10.50.1
subnet: 255.255.0.0
gateway: 10.10.1.1
dns1: 10.10.1.1
dns2: 0.0.0.0
use_address: 10.10.50.1
ap:
ssid: ESPectre Test 1
password: REDACTED
ap_timeout: 90s
domain: .local
reboot_timeout: 15min
power_save_mode: LIGHT
fast_connect: false
enable_btm: false
enable_rrm: false
passive_scan: false
enable_on_boot: true
min_auth_mode: WPA2
networks:
- ssid: REDACTED
password: REDACTED
priority: 0
external_components:
- source:
url: https://github.com/francescopace/espectre
ref: main
type: git
components:
- espectre
refresh: 0s
espectre:
id: espectre_csi
movement_sensor:
name: 'Office Node #1 - Movement'
disabled_by_default: false
force_update: false
unit_of_measurement: ''
accuracy_decimals: 2
state_class: measurement
motion_sensor:
name: 'Office Node #1 - Motion'
disabled_by_default: false
device_class: motion
threshold_number:
name: 'Office Node #1 - Threshold'
disabled_by_default: false
mode: AUTO
icon: mdi:pulse
entity_category: config
segmentation_threshold: 1.0
segmentation_window_size: 50
traffic_generator_rate: 100
lowpass_enabled: false
lowpass_cutoff: 11.0
hampel_enabled: false
hampel_window: 7
hampel_threshold: 4.0
normalization_enabled: false
normalization_target: 28.0
sensor: []
binary_sensor: []
number: []
Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @studiobts, I've just pushed a fix that pauses the traffic generator during the calibration phase:
You can see it in the logs: This should eliminate those Thanks for your support, |
Beta Was this translation helpful? Give feedback.
-
|
The error messages have disappeared, but the behavior is identical to before, with continuous pauses and freezes. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for testing, part of the fix works - no more However, looking at your logs, I see a different issue: there are huge gaps in CSI packet reception: And again: This is not related to the traffic generator fix. The CSI driver seems to be dropping packets or losing synchronization. wifi:
power_save_mode: LIGHTWiFi Power Save mode interferes with CSI packet reception. When power save is enabled, the WiFi radio periodically sleeps, likely causing the gaps you're seeing in the logs (43 seconds, 16 seconds, etc.). Please try to change to: wifi:
power_save_mode: NONELet me know if this helps! |
Beta Was this translation helpful? Give feedback.
-
|
Yes, exactly, these are the issues I reported to you in the various logs. Regarding To be safe, I will also test with another ESP32 I have available. I will keep you updated! |
Beta Was this translation helpful? Give feedback.
-
|
I ran several tests, and this is what I noticed, even though I can’t provide a technical explanation for it:
I will try moving the ESP32 to a greater distance than its current one to see what happens. It’s possible that the problem is due to some very peculiar aspect of my setup; I hope it can still be of some help. If you think it isn’t, let me know—no problem. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the incredible work. At the moment I only have ESP32 boards available, and from what I have read in the release notes the new feature is not available. I have ordered a couple of ESP32-S3 DevKit boards so I can try ESPectre with a supported board. In any case, I have upgraded to the latest release and I can tell you that the issue I described has been reduced but is still present: now it does not happen with every sudden movement, but only after some of them. Yesterday I ran several tests with different parameter settings to try to reach a stable configuration, but unfortunately I was not able to obtain any meaningful results. I followed the tuning guide, but in the many tests I performed either the movement was not detected because the measured value was too low, or even with no one at home the value increased for no apparent reason, effectively always going above the threshold I had previously identified as the limit for detecting movement. Is it possible that all of this depends on the fact that I am using ESP32 boards? |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I don't have an original ESP32 board myself, so I haven't been able to test and debug these specific issues. At this point, I need to order one to understand exactly what's happening and potentially improve support for this platform (if possible). The ESP32 was the first chip in the family and its CSI implementation is less refined compared to newer variants. In the documentation, I marked ESP32 as " The same happened with ESP32-C6 (see this issue), but once I got the device we solved the problem together. Let me ask Santa to bring me this board for Christmas! 🎅 In the meantime, the ESP32-S3 you ordered should work much better - it's the platform I use daily and have tested extensively. |
Beta Was this translation helpful? Give feedback.
-
|
I tested it with the ESP32-S3 Dev Kit. After the first ESPHome flash (with the board placed on my desk), everything seemed to be working correctly: no freezes, a stable motion value (between 1 and 2), and as soon as I moved (head, arms, etc.) the value increased, accurately reflecting what was happening, sometimes reaching values of 15–20. However, after moving the board to a more convenient position (to a corner of the same desk, a bit farther away from me), the freezes returned and the motion level changed radically: always very low (0.1–0.3) and no movement detected, not even very abrupt ones. From ESPHome I cleaned the build files and performed a new flash to make sure the calibration was executed again correctly as indicated in the guide, but nothing changed—the situation is identical. I’m sure I’m doing something wrong, but honestly I don’t know what. |
Beta Was this translation helpful? Give feedback.
-
|
Calibration runs at every boot, not just on flash. No need to reflash — just press reset or power cycle. Also, calibration must be performed in the final position. If you calibrate on your desk and then move the board to a corner, the calibration becomes invalid because the RF environment is completely different. To recalibrate properly:
Could you share the detailed logs from boot? Look for: The baseline variance will help diagnose if calibration is working correctly. I've never encountered freezes with the S3. There might be heavy interference in that corner — have you tried other placements? |
Beta Was this translation helpful? Give feedback.
-
|
@studiobts I finally received an ESP32 from Amazon. I did find a calibration issue on this device, which I fixed in commit cc3d4aa, but it’s unrelated to the freezes you’re seeing. Since the S3 shows the same behavior in your setup, it’s very likely there’s significant interference in that area.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Very interesting project, I’m testing it on some boards I have at home, in particular various development boards with ESP32-WROOM-32 or similar. I used the provided example configuration as a starting point; below is the complete one I’m using:
I noticed a few things:
Beta Was this translation helpful? Give feedback.
All reactions