I have a Davis 6410 wind gauge connected to an ESP32, which until recently has worked perfectly.
But after the latest update of HA 2026.2.2, the wind gauge has gone bananas.
Instead of the normal 2–4 m/s, it now sometimes shows over 750 m/s!
Something has changed with the ESP32 pulse counter, but I can’t find what’s wrong. Could it be a bug?
Can you please see anything wrong in my code below?
### REFERENCE MEASUREMENT m/s ###
Translated with DeepL.com (free version)
- platform: pulse_counter
pin:
number: GPIO34
inverted: true
mode:
input: true
name: "Vinddata"
id: vinddata
icon: "mdi:weather-windy"
unit_of_measurement: "m/s"
device_class: "wind_speed"
update_interval: 1s
accuracy_decimals: 1
filters:
- multiply: 0.0167625
#- lambda: return ( x * 2.25 / 60.0 ) * 0.447;
# Rådata in under 1-sekunders period
### AVERAGE WIND ###
- platform: template
name: "Medelvind"
id: medelvind
unit_of_measurement: "m/s"
device_class: "wind_speed"
icon: "mdi:weather-windy"
lambda: |-
return 1*id(vinddata).state;
accuracy_decimals: 1
update_interval: 3s
filters:
- sliding_window_moving_average:
window_size: 200
send_every: 200
send_first_at: 30
# Medelvind var 10:e minut
### GUST WIND ###
- platform: template
name: "Byvind"
id: byvind
unit_of_measurement: "m/s"
device_class: "wind_speed"
icon: "mdi:weather-windy"
lambda: |-
return 1*id(vinddata).state;
accuracy_decimals: 1
update_interval: 1s
filters:
- max:
window_size: 3
send_every: 3
- max:
window_size: 400
send_every: 200
Similar problem here. Reading a power meter via S0 for 6 years now without any trouble, but since I updated to 2026.2.0 today, I get readings that are totally implausible.
Example config:
- platform: pulse_counter
pin: GPIO27
unit_of_measurement: 'W'
accuracy_decimals: 1
name: 'el. Leistung WP Heizstab ESP'
update_interval: 3min
filters:
- multiply: 30
total:
unit_of_measurement: 'kWh'
accuracy_decimals: 1
name: 'Stromzaehler WP Heizstab ESP'
filters:
- multiply: 0.0005
edit:
I also tried this configuration, but it didn’t help:
- platform: pulse_counter
pin:
number: GPIO27
mode:
input: true
pullup: true
JulianDH
(Julian Hall)
February 20, 2026, 12:39pm
3
I use Davis 6410 / ESP32 and I am on the latest ESPHome 2026.2.0 and my pulse counter is working. What ESPHome version are you using? Would it help to add my YAML
Yes, I am also using version 2026.2.0.
In light winds, the values appear normal, but if the wind increases, the values become completely abnormal.
However, please post your code so that I can see what distinguishes them.
I also use an Davis 6410 although I’m using pulse_meter.
- platform: pulse_meter
pin:
number: GPIO4
mode: INPUT
name: "Wind Speed"
id: wind_meter
unit_of_measurement: 'mph'
accuracy_decimals: 1
filters:
- multiply: 0.0248571 #1.492mph per rotation so 1 / 60 / 2 * 1.491424
- sliding_window_moving_average:
window_size: 10
send_every: 10
- timeout:
timeout: 10s
value: 0
Note: mine only has one pulse per rev as I replaced a bad reed switch with a hall sensor. Its been solid for two years now.
JulianDH
(Julian Hall)
February 20, 2026, 10:07pm
6
Sorry I meant I use pulse meter. I see ESPHome 2026.2.1 is just out and has a pulse meter fix for certain ESP32 variants. I would try this first.
neel-m
(Neel Malik)
February 21, 2026, 6:43pm
7
dev ← swoboda1337:fix-pulse-counter-glitch-filter
opened 11:57PM - 19 Feb 26 UTC
# What does this implement/fix?
The `max_glitch_ns` calculation used `1000000` … (10^6) instead of 10^9 when converting `PCNT_LL_MAX_GLITCH_WIDTH` ticks to nanoseconds. This made the computed maximum 1000x too small (12ns instead of 12787ns), causing `std::min` to cap the user's requested filter (e.g. 13000ns for 13µs) to just 12ns. ESP-IDF then converts that to 0 APB clock cycles — effectively disabling the glitch filter entirely.
With the filter disabled, the PCNT hardware counts electrical noise as pulses, producing wildly inflated readings (e.g. ~280,000 pulses/min instead of ~1,010 on an ESP32-C6).
This fix uses the same split-division approach as ESP-IDF's own `pulse_cnt.c:404` to stay in 32-bit arithmetic:
```c
// ESP-IDF (ns → cycles): cycles = (freq / 1000000) * ns / 1000
// ESPHome (cycles → ns): ns = cycles * 1000 / (freq / 1000000)
```
## Types of changes
- [x] Bugfix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Developer breaking change (an API change that could break external components)
- [ ] Code quality improvements to existing code or addition of tests
- [ ] Other
**Related issue or feature (if applicable):**
- fixes https://github.com/esphome/esphome/issues/14069
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):**
- N/A
## Test Environment
- [ ] ESP32
- [x] ESP32 IDF
- [ ] ESP8266
- [ ] RP2040
- [ ] BK72xx
- [ ] RTL87xx
- [ ] LN882x
- [ ] nRF52840
## Example entry for `config.yaml`:
```yaml
sensor:
- platform: pulse_counter
pin: GPIO18
name: "Pulse Counter"
internal_filter: 13us
```
## Checklist:
- [x] The code change is tested and works locally.
- [ ] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphome-docs](https://github.com/esphome/esphome-docs).
This is the fix that is likely needed. Appears to be for all esp32.
2 Likes