A low cost decibel meter to use on openHab

I have made a low cost dB meter that almost any-one can build. This sound meter sends the data by MQTT so it can be easely used in openHAB. The costs are less then € 7.50

It is based on the great work from Ivan Kostoski. The adaptions I have made is the MQTT connection.

Find the description to make one yourself at github.

6 Likes

I have absolutely no need for this, but now I want to make one! Thanks for sharing!

3 Likes

I actually could use this and was contemplating how to do something like it. In my case, I use OH to broadcast TTS messages over a whole home audio system. Depending on some situations, the ambient noise can be quite high, so being able to adjust volume based on ambient decibel levels would be really useful! Thanks for sharing this!

2 Likes

No apparent need here either at the moment, but I ordered the microphone and will build it once I received it :slight_smile:

Thanks

In another thread it was suggested to use the decibel meter to detect the sound of non-connected smoke detectors to start a rule and or notifications.
I think there are many situations to think of where it is useful.

This sounds a great idea to me as well.

Hi @Charley. Thanks for your project.

I have made dBmeter exactly the same as yours and it seems to bew orking just fine.
In MQTT Explorer I can see it is reporting very well. But when chceked /var/log/mosquitto/mosquitto.log it is full of errors:

1637259513: New connection from 192.168.0.137 on port 1883.
1637259513: New client connected from 192.168.0.137 as dBmeter-592d (c1, k15, u'openhab').
1637259882: Client dBmeter-592d has exceeded timeout, disconnecting.
1637259882: Socket error on client dBmeter-592d, disconnecting.
1637259892: New connection from 192.168.0.137 on port 1883.
1637259892: New client connected from 192.168.0.137 as dBmeter-fd2f (c1, k15, u'openhab').
1637260006: Client dBmeter-fd2f has exceeded timeout, disconnecting.
1637260006: Socket error on client dBmeter-fd2f, disconnecting.
1637260030: New connection from 192.168.0.137 on port 1883.
1637260030: New client connected from 192.168.0.137 as dBmeter-7436 (c1, k15, u'openhab').
1637260053: Client dBmeter-7436 has exceeded timeout, disconnecting.
1637260053: Socket error on client dBmeter-7436, disconnecting.
1637260055: New connection from 192.168.0.137 on port 1883.
1637260055: New client connected from 192.168.0.137 as dBmeter-2ec9 (c1, k15, u'openhab').
1637260264: Client dBmeter-2ec9 has exceeded timeout, disconnecting.
1637260264: Socket error on client dBmeter-2ec9, disconnecting.
1637260280: New connection from 192.168.0.137 on port 1883.
1637260280: New client connected from 192.168.0.137 as dBmeter-15ee (c1, k15, u'openhab').
1637260351: Client dBmeter-15ee has exceeded timeout, disconnecting.
1637260351: Socket error on client dBmeter-15ee, disconnecting.
1637260364: New connection from 192.168.0.137 on port 1883.
1637260364: New client connected from 192.168.0.137 as dBmeter-3bd7 (c1, k15, u'openhab').
1637260533: Client dBmeter-3bd7 has exceeded timeout, disconnecting.
1637260533: Socket error on client dBmeter-3bd7, disconnecting.
1637260538: New connection from 192.168.0.137 on port 1883.
1637260538: New client connected from 192.168.0.137 as dBmeter-f26d (c1, k15, u'openhab').
1637260562: Client dBmeter-f26d has exceeded timeout, disconnecting.
1637260562: Socket error on client dBmeter-f26d, disconnecting.
1637260563: New connection from 192.168.0.137 on port 1883.
1637260563: New client connected from 192.168.0.137 as dBmeter-dcea (c1, k15, u'openhab').
1637260826: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1637260904: Client dBmeter-dcea has exceeded timeout, disconnecting.
1637260904: Socket error on client dBmeter-dcea, disconnecting.
1637260928: New connection from 192.168.0.137 on port 1883.
1637260928: New client connected from 192.168.0.137 as dBmeter-e019 (c1, k15, u'openhab').
1637261040: Client dBmeter-e019 has exceeded timeout, disconnecting.
1637261040: Socket error on client dBmeter-e019, disconnecting.
1637261050: New connection from 192.168.0.137 on port 1883.
1637261050: New client connected from 192.168.0.137 as dBmeter-581d (c1, k15, u'openhab').
1637261143: Client dBmeter-581d has exceeded timeout, disconnecting.
1637261143: Socket error on client dBmeter-581d, disconnecting.
1637261160: New connection from 192.168.0.137 on port 1883.
1637261160: New client connected from 192.168.0.137 as dBmeter-53a7 (c1, k15, u'openhab').
1637261184: Client dBmeter-53a7 has exceeded timeout, disconnecting.
1637261184: Socket error on client dBmeter-53a7, disconnecting.
1637261221: New connection from 192.168.0.137 on port 1883.
1637261221: New client connected from 192.168.0.137 as dBmeter-e53e (c1, k15, u'openhab').
1637261273: Client dBmeter-e53e has exceeded timeout, disconnecting.
1637261273: Socket error on client dBmeter-e53e, disconnecting.
1637261282: New connection from 192.168.0.137 on port 1883.
1637261282: New client connected from 192.168.0.137 as dBmeter-ed77 (c1, k15, u'openhab').
1637261397: Client dBmeter-ed77 has exceeded timeout, disconnecting.
1637261397: Socket error on client dBmeter-ed77, disconnecting.
1637261403: New connection from 192.168.0.137 on port 1883.
1637261403: New client connected from 192.168.0.137 as dBmeter-4731 (c1, k15, u'openhab').

Have you ever checked it in your log file?
Is it a problem with code itself?

Hello @kristofejro ,

I have just checked my mosquitto.log and remarkably I have the same error in the log.
Will try to find out why this happens during the weekend.

In my system I have 7 ESP32 running and only ONE is giving the issues. Not my dbMeter but a detector that checks if the alarm system has been switch on and several other ON/OFF functions of the alarm system.

1637307963: Socket error on client PinsATS-ec76, disconnecting.
1637307963: New connection from 192.168.178.166 on port 1883.
1637307963: New client connected from 192.168.178.166 as PinsATS-d235 (c1, k125, u'admin').
1637308200: Socket error on client PinsATS-d235, disconnecting.
1637308201: New connection from 192.168.178.166 on port 1883.
1637308201: New client connected from 192.168.178.166 as PinsATS-3d8b (c1, k125, u'admin').

It seems that the Socket is disconnected about 240 seconds after the connection 1637307963 - 1637308200 = 237 seconds

I already noticed that the ESP doesn’t send the proper data to my OH3.

It might be a problem in the ESP32. This weekend my first option is to swap the ESP32 for another one.

I have been looking at issues in the pubsubclient at github.

*** Update ****
The issue is not in the library, but it might be the module that you are using. Same for me 6 modules are working perfect only 1 is troublesome.

If you did everything correct and issue still persists, check if you have a reliable and stable module. It turned out all with the same settings, I still see server timeout on some cheaper ones, which never happens when I use decent modules on my product.

Thanks @Charley for the answer.

It may be ustable. I don’t dobut it. I don’t even remember where my was bought.
How can I check it if it is reliable?
Do you have any example on the web of such reliable module?

Hello @kristofejro,

On my ESP32 i have pinpointed the issue.

I have 12Volt from the alarm system and made a small PCB with an 12Volt to 3.3Volt buck converted next to the ESP.
There is some interference that drops the RSSI from the WiFi below -77
(you can request the RSSI from the WiFiClient and publish it with MQTT (and see results in MQTT Explorer)

Please check if you have no interference from other devices near your ESP (Chargers, Dimmable LED power supplies etc.)

I have ordered some new ESP32 from banggood

The pinout is slightly different from my previous ones But a newer version of the ESP32 itself.

They come in on Thursday From Czech Republic will give it a try in the next weekend.

I bought two new ESP32 and this issue is present on both of them.
I have performed some tests and have some conclusions. I was using youtube and playing music :slight_smile:

When it detects sound volume level change (music is playing) then there is no error in the log.
When the sound volume level drops to the level when it does not detect any change (music is stopped) then there is a timeout after about 20-30 seconds in the log

Client dBmeter-7547 has exceeded timeout, disconnecting

and it is disconnecting

Socket error on client dBmeter-7547, disconnecting.

Then when sound is detected again (played music again) device is connecting

New connection from 192.168.0.137 on port 1883.
New client connected from 192.168.0.137 as dBmeter-a836

This pattern can be reproduced anytime.

In the code, there is a threshold of 1.5db line 29

double dBdifference = 1.5;

If the sound difference is 1.5 or fewer dB difference, it won’t send (dB is a logarithmic scale). As long as sound level is changing more than 1.5dB it will report to MQTT. If the sound doesn’t change that is when the issue starts because of a time out. (see mqtt client exceeds timeout and disconnects · Issue #810 · knolleary/pubsubclient · GitHub)

You could increase the Timeout length in the pubsubclient library or change line 29 threshold to .05dB

Did you try to place the ESP on another location?

My new ESPs came in yesterday, will give it a try in the weekend.

You could increase the Timeout length in the pubsubclient library

But how to do it? :slight_smile: If you could write the code and tell me where to put it.

(you can request the RSSI from the WiFiClient and publish it with MQTT (and see results in MQTT Explorer)

and this

I would like to check both of these options but I am not a programmer so have no idea how to handle this.

Did you try to place the ESP on another location?

Yes. I tried in few location without any other electronic devices near. But the result is the same.

I have deleted most of this message

line 483 of the code

void loop() {
    // Nothing here..
}

This parts will not be called because of a while loop in the set up.
I will get back to you later.

At the moment I have no ESP32 available at my work to check.

I have done some quick tests.

You could try to make a few changes in the code

at line 463

// Serial output, customize (or remove) as needed
            Serial.printf("%.1f\n", Leq_dB);

            if (abs(Leq_dB-baseDB) > dBdifference) {

change to

// Serial output, customize (or remove) as needed
            Serial.printf("%.1f\n", Leq_dB);
            mqttClient.loop();        // add this line it should keep the mqttClient alive
            if (abs(Leq_dB-baseDB) > dBdifference) {

further in the code if you wish to check the RSSI

line after line 474

...    
    // start of addition
    String strValue = (String) WiFi.RSSI();
    int msgLen = strValue.length();
    mqttClient.beginPublish("dBmeter/rssi", msgLen, true);
    mqttClient.print(strValue);
    mqttClient.endPublish();
    // end of addition
    baseDB=Leq_dB;
...

If this doesn’t work, I do not know how to workaround the pubsubclient issue.

1 Like

Now it works perfect :slight_smile:
After 15 hours of testing there were no errors nor disconnects!

RSSI reporting is working fine. Now I know that my average for that module is -55 dBm :slight_smile:
mqttClient.loop(); seems to be doing good job.

I have just changed “dBdifference” to 1.0 and “msgLen” for publishing rssi to something else because this was already used for soundlevel reporting.

Thanks again @Charley for your effort and support!

Hello @kristofejro ,

Happy to that your ESP is working now. There was no need to rename the msgLen you could have just deleted the int declaration before msgLen.

Just because of copy and paste, I forgot to remove the int, my bad.