Reading a DHT11/22 on a raspberry and send the results by MQTT

There are several items in the community forum about reading a DHTxx sensor, but I couldnt find anything comprehensive in the Tutorials and Examples… so, I guess the task to write a practical Tutorial is up to me.

As for coding it is no use to re-invent the wheel, I fortunately found someone on this forum (@psyciknz ) had done most of the work, albeit for a DHT22, while I am using a DHT11 but that was easy to alter.

For the next steps I presume you already have python installed. Jessie already should have python 2.7 installed.

The Python program calls a few libraries that you most likely already have, maybe with exception of the paho.mqtt.client and the adafruit DHT library.

the mqtt client can be installed as follows:

pip install paho-mqtt
if for whatever reason this does not work for you, try:

git clone (=> download the client)
cd paho.mqtt.python (=> go to proper directory)
python install (=> install the client)

depending on how you are logged in you may need to add ‘sudo’ before the install commands

The mqtt client is now installed.

For the DHT library do the following:

git clone => download the library
cd Adafruit_Python_DHT => go to proper directory

Before you install the library, you need some dependencies that may or may not be on your system:

sudo apt-get update
sudo apt-get install build-essential python-dev python-openssl

If you already had modules installed those will be skipped.
Then install the library:

sudo python install (=> install the library)

At this moment it is a good idea to restart your raspberry.
If you want -when your raspberry is back up and running- you could now try one of the example programs in the Adafruit DHT library, just to make sure everything is working.
Connect your DHT11 to e.g. GPIO4 of your raspberry.
Make sure you are still in directory: /home/openhabian/Adafruit_Python_DHT


 cd examples
 sudo ./ 11 4

You will get the temperature and Humidity reported in your terminal

Now download the DHT_sensor program.

If like me you want to use a DHT11 instead of a DHT22, change line 45:
DHT_TYPE = Adafruit_DHT.DHT22
DHT_TYPE = Adafruit_DHT.DHT11

And save the program on your raspberry. Be careful in editing though. Python is rather picky regarding indents and you could easily get error messages if you are not careful. I suggest you just change the number 22 into 11 if you are using a DHT11. Don’t change anything else unless you are confident in what you are doing.

I saved it directly in my home/openhabian directory, i.e. the directory that is availble directly after logon

Now have a look at the usage instructions in the program (lines 36-42), but beware:
Presuming you saved the program as “”, that is the name you need to use instead of “” (the name mentioned in the “Usage”).

make sure you have execution rights to the file. I usually set priviliges to 0777, I do that direct through webmin but you could also do chmod +x
For testing I started my program as follows:

./ 'cupboard/temperature1' 'cupboard/humidity1' 4

This says that as my mqtt topics I have cupboard/temperature1 and cupboard/humidity1 and my DHT11 sensor is attached to GPIO pin 4 while the refresh rate is 300 seconds (the default).

To make it a bit easier I created a file called “” that contained the single line:
./ 'cupboard/temperature1' 'cupboard/humidity1' 4 50
That does the same as the earlier line, but now I set the refresh rate to 50 seconds. I put it in one file because that is easier to type than having to type the main program with the arguments. Again, make sure you have execution rights to this file by setting chmod +x

If you want you can make the file to automatically start at boot as I describe below.

The MQTT messages are subsequently sent out over the network.

And one could use definitions like below in your OpenHAB Items file to use them in OpenHAB

Number Cupboard_temp "Riser temperatuur [%.1f °C]" <temperature> (GF_Corridor) {mqtt="<[mosquitto:cupboard/temperature1:state:default]"}
Number Cupboard_humidity "Riser humidity [%.0f %%]" <line> (GF_Corridor) {mqtt="<[mosquitto:cupboard/humidity1:state:default]"}

Starting the script at boot
The script will run perfectly when started manually, but it will run in an instance of the SSH window and the moment you close that window, the script will stop. It is therefore better to have the script starting at boot. This is simple to do, but you have to be aware of the full PATH you are using.
Change the content of the dht.s file as follows:
Then in your preferred editor open the etc/rc.local file and add a line (the line at the red arrow):

The “&” behind the filename is to ensure the rc.local file does not wait for the (endless) script to finish.
Save the file and reboot. You will now no longer see the temperature and humidity in an ssh window, but the MQTT commands are being sent.

Though I do not want to say much about python programming (I am a beginner in that myself), just a few tips in case you start changing this file: python programs can be started by typing
They can also be made executable by the command chmod +x
after that they can be run with:
However, in that case you need to tell the ‘executer’ where to find the python interpreter.
you do that by adding #! /usr/bin/python as the first line of your python file.
If you do not, the program will choke on the first ‘From’ and throw a can't read /var/mail/ error

Just a final remark: I am no real fan of the DHT11 or DHT22. They are not very accurate and prone to failure. If not for the Humidity I would prefer a DS18B20 and currently am looking into the BME280 as that measures humidity as well (Edit: after a short discussion on failing DHT sensors, it could very well be that they do a lot better/last longer in relatively dry climates)

Added: Errors
If you install the above on an openhabian system you are unlikely to get any errors. However, I tested it on a freshly installed raspian Stretch system (not sure anymore if it was ‘Lite’) and I came upon the following Errors that were easy to fix:
-bash: git: command not found
sudo apt-get install git
File “”, line 5, in
from setuptools import setup, find_packages
ImportError: No module named setuptools
sudo apt-get install python-setuptools
no module named requests
sudo pip install requests
No pip
apt install python-pip #python 2
Append error, logging in again: [Errno -2] Name or service not known
Most likely you are running the file from another raspbery where your MQTT server is not located. Make sure you alter the variable ‘servername’ in the file into th eservername or ip number where your mqtt broker is situated. Also make sure you do not have two clients running with the same name.

If you want to do it completely different,look here.


I am very new at this topic. Bare with me.

Don’t you have to make DHT_sensor program executable?
chmod +x

Thanks a lot for the work.


ah yes, I was already thinking of putting that in. Need to make it executable. Usually I set the privilige at 0777
Of course you only need to make it executable if you run the program with “./” if you run it with “python” that is not necessary

1 Like

can you say something about the mosquitto server installation?

The Mosquitto broker does come with the openhabian distro, but you need to activate it in the config utility.
If you are not using openhabian but installed openhab manually, you need to download and install the mosquitto server.
Subsequently you have to install the MQTT broker and configure it for Mosquitto

1 Like

Thanks for posting. This is a great tutorial. Some kind soul added DHT support to sensorReporter awhile back so I’ve been looking at using that. Reviewing their code it appears very much inline with what you have written.

Interesting. I’ve been running two (22s) and they seem accurate enough for my purposes and seem to be doing so for the past year or so. What should I be watching out for with them? So far their readings are close enough to other sensors I have in the house to be reasonable. I’d say they are within a few degrees F and within 5% humidity.

1 Like

Thanks for your kind words Rich. I indeed had seen your github code with interest, but I guess in the end I sort of flipped a mental coin which one it was going to be. You do have quite a number of interesting other codes there.

With regard to the accuracy, I might have been a bit too condensed. The DHT22 is indeed more accurate than the DHT11. I have had a number of DHT11 that would give up, sometimes for unknown reasons (suddenly giving values far off) or after they had been in conditions that were too humid.
Had only one DHT22 as that one at least had a wider range but that one just stopped after a while, so maybe it is just a stroke of bad luck. There seems to be a warming up and cooling cycle that can revive them but I never bothered.
Having said that, I still use the DHTxx for situations where it is not so important if I know whether the RH is 75% or 65%, but for accurate temperature measurements I go to the DS18B20.
But if I have to combine a DS18B20 (for temperature) plus a DHT11 (for humidity), the BME280 becomes an interesting choice.
So, Let’s say I do have ‘concerns’ over the DHTxx, but I still do use them (coz I still have a a handful laying around)

That makes sense and was my first guess. I live in a very dry climate. I have to run humidifiers all day during winter in the bedrooms just to keep the humidity up to 30%. The rest of the house lives between 20%-25%. So the dry conditions may be insulating me from problems.

Thanks for the description of the issues you’ve seen. I’ll know what to look out for. I need to rebuild my sensors anyway. I’ve given up on RFM69HW. I think the interference in my area has grown too much over the last few months. More and more I’m not able to receive the sensor readings at all. I’ve some ESP8266s that I’ll try to set up to replace them. They are smaller than the Arduino Unos too so I can make smaller cases for them.

1 Like

That could very well explain the difference in survival rate.

I have played around with the RFM69HW but didnt find it worth the trouble, though I probably will do a bit more with them just out of interest.
As I understand the RFM69 uses less power than the ESP8266, Not really important when on a grid fed PSU, but a big difference when on batteries

1 Like

I use some SHT30 sensors with Wemos D1 mini (ESP8266 boards) for all my sensors. IMO they are more reliable and accurate than the DHTXX and I live in a pretty extreme climate location (Québec). Temperatures go from -40°C to + 40°C through the year, so outdoor sensors must accept this.

If you’re looking to implement some ESP8266 based sensors (none of mine are battery powered atm), I strongly suggest to give a look to the homie library :

It really get your code simple, as well as taking care of the most annoying things (checking connections, dynamic configuration of boards without harcoding wifi and MQTT credentials, etc.) and it supports OTA and deepsleep for battery powered sensors. I tested both OTA and Deepsleep functions, which worked seemlessly.

Best regards

Thanks Gaël
I have been looking at the SHT30, and they are a good replacement for the DHTxx.
I currently already do have an ESP program that reads a BME280 via I2C, has OTA and deepsleep and it is not really a big issue to put an SHT30 on there as that is also I2C. It will work on a Wemos, but I am using a bare 12-F for energy efficiency (so I can use it on battery if necessary) (will upload it somewhere and leave a link here)

i use my DHT11 just indoors as it can’t handle low temperatures at all, but when they need replacing, I may go for the STH30.

1 Like

Thanks Again, can you tell me how to install the MQT broker and how to configure it?

How did you install your Openhab? manually, or from an openhabian distro?

1 Like

i installed Openhabian

then go to your terminal and type 'sudo openhabian-config
choose option 20 (other components) and then option 23 mosquitto.
That will install mosquitto.
Subsequently you have to install the MQTT binding in paperUI.
Then open the file openhab-conf/services/mqtt.cfg.
the minimal thing to do there is to define your broker, e.g like I did in the last line in this screenshot:
I named my broker ‘mosquitto’ but you can choose another name if you want


Do never, ever, set the rights on files to 777. That is like the old bad days of MS Windows.
You should never give world the right to write to your programs. That are a really bad idea.

Much better to use chmod +x as suggested. That is, make the file executable, leave the rest as it is. You might want to remove write to all but the owner of the file. Use this command to do that chmod +x,go-w Notice the spaces, or absence of spaces here, are important.

Thanks Jaxon. I do understand your concerns but there is no such thing as “never, ever” in setting filename priviliges. It comes down to a personal choice and needs.
The chmod +x adds executability to the privileges no matter what their previous status and in the end the difference between say 755 and 777 is that the file is editable by group and others, not just the owner.
I work from several stations and not always via ssh so I am not always the ‘owner’ of my own files, hence 0777. Whether that is the right decision for others I cannot say. In a tutorial I can only say how I did it (0777) and how they COULD do it (chmod +x).
Nevertheless you point out something that might be of importance to others

No one else can log into my system and if someone could I have bigger worries than a py file being altered :wink:

I live in the Pacific Northwest and have had a DHT22 running in my garage for a couple of years. It is constantly giving me RH of 90% or more for 9 months of the year. Never had an issue with it. I have seen an occasional obviously wrong number but never enough to make a difference particularly since it doesn’t trigger anything. I’m in the process of implementing a second DHT22 which will control heating so I am planned to use an Exponential Moving Average just to cull the outliers. All in all though, I’ve found the DHT22s to be reliable and accurate enough. Always within 1 degrees of my Ecobee temperature monitors.


Thanks for that insight Mark, that is good to hear. Maybe I just have been unlucky with my DHT11’s. There is no doubt though that the DHT22 is more accurate than the DHT11.
In spite of my reservations, I have just ordered an AM2302 (basically a DHT22 in a nice package). My main reasons being ease of operation and that it comes in a spouse friendly casing.

Although the DHT22 goes to lower temperatures, outside I use a BME280, as it has Barometric Pressure as well and is more suitable for battery feeding.
As I still have a bunch of DHT11’s they will be wherever there is no need for high accuracy, and will use them till I run out. Who knows what will be on the market to replace them when they do give up.

As far as ‘occasional wrong numbers’ go, on a recently installed DHT11 I see an RH reading of 40%. Occasionally it just jumps to 60% and then goes back to 40 ( or ‘in that ballparc’). No problem as like in your case, it doesnt trigger anything.

So where I earlier said ‘I am not a fan’, let’s call it an ‘up and down’ relationship

1 Like

FYI, there is also pre-installed kernel module for this, you just need to activate it in raspbian. That outputs the sensor data as text under /proc filesystem, which you can grep directly into mqtt message. No python stuff needed necessarily. That’s what I used. If anyone is interested, I can fire up the raspi one day and copy paste the config option for boot.

See dht11 enablement here:

Simple and efficient.