In case anyone still needs info on how to make this work with an ESP32, here’s what I changed:
-I changed the pin used for the analog input from the mic from A0 to GPIO36 and connected the wire there.
-Everywhere 1024 appears in the code, I changed it to 4096. This is because the ADC in the ESP32 uses 12 bits (4096) instead of 10 (1024). There should be 5 occurrences of this. One setting an initial value, one in a loop, and 3 in a couple of “map” functions.
With these two changes, a sensor using the ESP32 behaves the same as one using the 8266 (D1 Mini). I have both processors so I was able to confirm this.
I developped my own volume meter prototype based on a pre-calibrated volume meter + a raspberry pi to run my python scripts. I reached out to you by email but didn’t get an answert (yet?) @Reubertt as I’d like to figure out ways to manufacture way cheaper volume meters. (my own pre-calibrated device costs approx 100$ per device including a rpi02W)
I also added MQTT to Noisebuster, which results in this (but to be honest, I did not take the time to dig the HA dashboard capabilities) :
If anyone here wants to work to make a viable product out of this, reducing the production costs, and improving the openCV capabilites to count the vehicles, I’m all ears !
there is a discord server you can join by the way : NoiseBusters
PS C:\PortbleApps\ESPHome> esphome run esp32-tuinhuis.yaml
INFO ESPHome 2024.7.2
INFO Reading configuration esp32-tuinhuis.yaml...
Failed config
binary_sensor.analog_threshold: [source esp32-tuinhuis.yaml:173]
platform: analog_threshold
name: ATS alarm triggered
Couldn't find ID 'volume_soundesp'. Please check you have defined an ID with that name in your configuration.
sensor_id: volume_soundesp
threshold:
upper: 110.0
lower: 80.0
device_class: smoke
disabled_by_default: False
FYI, I’m running ESPHome in HA on a raspberry pi. I’m not sure if your setup differs from mine such that it will affect whether or not this YAML code works.
Anyways, here’s the entire hunk of YAML that worked for me.
Note that I got rid of the encryption keys. Yours will be different anyways.
The way I created this was to add a new device, specify ESP32, but didn’t install it. I edited the YAML and added everything from web_server and below. The stuff above this was created when I initially added the device.
Thanks for adding the slider, it is really useful to find a good initial value.
However, the sensor doesn’t seem to work for me.
I adjusted the initial value to 5.6 (using the slider) to get a reading of 29.0 db, which matches the db of my silent room (measured with a calibrated reference decibel meter).
When I make some noise, the reading only goes up to 30 db, while my reference db-meter goes above 60-70 (talking or clapping hands).
Moreover, when I try to adjust the sensitivity via the slider, the measured db also goes up, which shouldn’t be the case.
Turning the potentiometer on the KY037 had almost no effect either.
Are you sure you are using analog output of the mic unit?
I have tinkered on this code with the help of Chatgpt and i learned a lot, especially the problem on the code/esp8266 wemos d1.
This code takes 500ms of sample with 2 seconds intervals which means the sensor doesn’t read 4/3 of the time. if you manage to get your clap detected feel lucky. I understood it made this was because a0 of 8266 also used to read wifi signal strength for device to work at all. So if try to get full sampling (1s read with 1s intervals) the Device doesn’t connect to wifi at all (code works flawless, you can read from serial usb) The best i managed was 1s analog read with 2s intervals.
I advise all who want to make this project to get a esp32.
After struggling with it for a couple of days, i think i figured this (erratic values that done make sense) out.
there are two leds on the module. one should be on, to indicate power…
the other should be off (when environment is silent).
In my case the second led was always on and i thought “I am not using digital output anyway, so who cares?” This was the mistake. If the second led is on even when its totally quiet, then we turn counter-clock wise until it turns off. Now when you make sound, the second led should come on. And then, the readings of the analog pin becomes much more logical and reasonable.
I couldnt get anything to make sense, until i observed that the calibration (potentiometer setting) matters.
Hi, this worked for me thanks (code above), tweaked for pin A0 on the d1_mini
I also wound out the screw until the led went off (in quiet room).
Performing much better now
Hi, Ive been playing around with KY-037 for week or two, I’ve read every post I can find and it seems to me that you can get great results if you are running HA on an Arduino. The videos show it works great so the proof is there but I have HAOS running on a PC.
There seems no way to get the code mentioned in the posts I’ve seen to give the same results, the code i see quoted in most posts shows a return voltage signal even without the KY-037 connected to the ESP32.
Maybe i should buy an Arduino to explore the differences.
I guess its just down to the code … interpreting the signal from the KY–37 and converting that to something equation db’s.
Any thoughts or suggestions anyone ?
Wow, it’s been a while since I wrote this code. I’ve improved my coding skills a bit, and it’s already quite outdated. Today I realized that this code has a bug where it can block Wi-Fi during polling. And now esphome works with external_components instead of custom_components, so I refactored the code and posted it on my github. Maybe it’ll solve some of your problems.
I haven’t been able to edit the original post yet, but here’s the new code.
For some reason it won’t compile on mine. I’ll try again later and report the error, but it was something to do with not finding init_.py for volume-sensor in the github component.
esphome:
name: volume-sensor
friendly_name: Volume-Sensor
esp8266:
board: nodemcuv2
external_components:
- source:
type: git
url: https://github.com/Reubertt/esphome-components
components: [volume-sensor]
#refresh: 1h
# Enable logging
#logger:
# Enable Home Assistant API
api:
encryption:
key: !secret apikey
ota:
- platform: esphome
password: !secret ota
# This automation is CRUCIAL for stability.
# It starts sampling slowly, then speeds up after Wi-Fi connects.
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "volume-sensor Fallback Hotspot"
password: !secret wifi_password
on_connect:
then:
- logger.log: "WiFi connected. Starting fast sampling."
- component.resume:
id: volume_sensor_main
# This sets the high-frequency sampling rate.
update_interval: 50ms
captive_portal:
sensor:
- platform: volume_sensor
id: volume_sensor_main
internal: true # The main component is just a controller.
pin: A0
# Start with a very long interval to allow Wi-Fi to connect reliably.
# The 'on_connect' automation above will override this.
update_interval: 100s
# Publish the peak value found every 5 seconds.
publish_interval: 5s
# Each sample burst lasts 30ms. The next burst starts immediately.
sampling_duration: 30ms
# --- Measurement Configuration ---
sensitivity: 50
# Use calibration to narrow the focus to your sensor's actual operating range,
# determined after completing the hardware calibration in Step 1.
adc_min_calibration: 200
adc_max_calibration: 900
# --- Child Sensors ---
db_sensor:
name: "Volume DB"
raw_max_sensor:
name: "Raw ADC Max"
raw_min_sensor:
name: "Raw ADC Min"
percentage_sensor:
name: "Volume Percent"
number:
- platform: template
name: "Sound Sensitivity"
optimistic: true
initial_value: 50
min_value: 0.0
max_value: 100.0
step: 0.5
set_action:
- lambda: id(volume_sensor_main).set_sensitivity(x);
I ended up refactoring everything, because my knowledge may have improved, but the sensor itself hasn’t, and I had the same confusion I had when I first developed it. I think looking at the official esphome repository, which now has a component very similar to mine, made me confused. Anyway, I’ve now managed to arrive at a stable, functional version that has no dependencies and is highly configurable. As I already said, the code is entirely on my github, including a calibration guide and how to improve the sensor and even an example of automation, I think it is quite complete and maybe I won’t need to touch this code for at least another 3 years.
I will give this a try for my toilet. Currently I have an airfreshener setup where it will auto spray if the light is on for +3mins. It works, but there are times we may need extra sprays. I am thinking whenever the toilet is flush, turn on the airfreshener.
You mentioned from your first post that voltage makes a lot of difference. Are you still using the 3.3v pin??
Yes, I’m using it at 3.3v, you can use it at 5v and have an improvement in noise, which ultimately depends on how you’re going to use it. Today, I’d say a low-pass filter would be more interesting, but again, I don’t see any advantage in making a system like this, as the microphone is really bad. If you’re going to do too many things, it’s better to get an Inmp441 with an esp32 supermini.
INFO ESPHome 2025.7.1
INFO Reading configuration /config/esphome/office-noise.yaml...
Failed config
external_components: [source /config/esphome/office-noise.yaml:9]
- source:
type: git
url: https://github.com/Reubertt/esphome-components
components:
Could not find __init__.py file for component volume-sensor. Please check the component is defined by this source (search path: /data/external_components/eea7c684/components/volume-sensor/__init__.py).
- volume-sensor
