Hi everybody!
I’m working with a dht11 used like a wireless sensor to monitor temperature and humidity inside my house, looking in their stats I notice that sometimes seems not correctly working on HA. I check using other mqtt app if the remote correctly send its values and it works, so the problem should be inside HA. These are the readings:
Somebody could help me? Maybe I send too often the readings by mqtt ? I check every 10 seconds…
I think that’s fairly standard for the dht11, you can get smoother results by making a stats sensor from the dht one, and graphing the mean from that, e.g. :
- platform: statistics
entity_id: sensor.dht11_temp
name: stats_dht11_temp
sampling_size: 10
The resulting sensor you want will then be:
sensor.stats_dht11_temp_mean
That said the dht11 isn’t meant to be a perfect device.
For a little more the dht22 is well worth the upgrade - and is sensitive enough to do away with the need for a stats sensor to achieve smoother looking graph values.
Stats sensors are always good to have though 
the DHT11 only gives a resolution of 1degree. You get what you buy
Yes obiouvsly dht 11 is not so detailed, but the Point is that sometimes seems to be blocked at hours ago… Like in the images
That means the sensor hasn’t detected any temperature / humidity changes in that timeframe.
The higher sensitivity of the dht22 would have detected changes over then and wouldn’t show as a straight line. It’s a limitation in the sensitivity of the dht11.
do you have a humidity reading? I’m experimenting with DHT22. It seems that the error rate inrceases if there is high humidity. Perhaps same problem with dht11?
in the graph you can see the outliers my dht22 produces… I mitigated the problem a little bit by repeating the readout of my dht22. but i have no clue why it measures 0 from time to time…
Mine seems to be more narrowly noisy I think, though I don’t have somewhere with similar value ranges to compare.
I’ve mine directly connected to the gpio on a pi zero, running hassbian & the dht22 component.
@r3n7on Would you mind posting the sensor config you’re using for this DHT11 sensor? You mentioned it’s using MQTT…
@linuxlurak Are your DHT22 values being published via MQTT? If so, are you using the retain flag for the published message?
@xstrex: thanks for asking!
MQTT? Yes. Retain: I don’t know…
This is my config:
sensor:
- platform: mqtt
state_topic: "home/living/usds-remote-1/state"
name: "uremotesds_temp"
value_template: '{{ value_json.temp }}'
unit_of_measurement: "°C"
- platform: mqtt
state_topic: "home/living/usds-remote-1/state"
name: "uremotesds_hum"
value_template: '{{ value_json.hum }}'
unit_of_measurement: "%"
As per the docs there seems to be no retain option.
Ah, in my arduino code there is this:
mqttClient.publish(MQTT::Publish(MQTT_COMMAND_TOPIC"/state", json).set_retain().set_qos(1));
Could this be influencing? It’s on the publishing side. But I’m not much into MQTT… Thanks for your help!
I would try firing up some kind of desktop mqtt tool (I like MQTT.fx), connecting to the server, and subscribing to the topic which is producing the “0” readings, then parsing the messages, to see if it’s actually a “0” at any point in time. This would remove HA from the equation.
If it is “0”, you can try setting the .set_retain(1).set_qos(1)); to see if it improves, but that’s just an educated guess, without looking over your Arduino sketch. The retain flag should retain the previous value, until the value changes (even if the next produced value is a “0”). But if the sensor is actually producing a “0”, then it sounds like a faulty sensor to me. The DHT22 should never produce a “0”, after initial startup, obviously unless the sensor reading is actually “0”, in which case, you’ve got bigger problems 
If you’re interested, here’s mine, I’ve got 3x of these running for several years now, and they never output a “0”.
@r3n7on Looking at your graphs, and reading about your problem; I’ve got to ask, do you have some kind of network connectivity issue between your DHT11 -> MQTT broker -> HA?
If you’re publishing readings every 10 seconds to MQTT, and you’ve configured the mqtt sensor component to read from the same topic, then you should have roughly 8640 readings in a 24hour period. But the graph you posted shows maybe 14 readings… Something doesn’t add up here.
@xstrex and this is the problem I think… Today I try to add a second sensor (in this case I use a dht22) and it seems that I have the same problem, also if the sensor send data every 10 sec it doest’t update … My project is based on :
HA–> MQTT broker --> Sensors (the first DHT 11 and the second DHT22)
Here my sensors config:
platform: mqtt
state_topic: ‘homeassistant/sensor/main_sensor/temperature_celsius’
name: “temperature”
unit_of_measurement: “°C”
platform: mqtt
state_topic: ‘homeassistant/sensor/main_sensor/humidity’
name: “Humidity”
unit_of_measurement: “%”
platform: mqtt
state_topic: ‘homeassistant/sensor/room/temperature_celsius’
name: “temperature sens2”
unit_of_measurement: “°C”
platform: mqtt
state_topic: ‘homeassistant/sensor/room/humidity’
name: “Humidity sens2”
unit_of_measurement: “%”
@r3n7on I understand what you’re saying, and your sensor setup sound fairly default to me. Also your mqtt component in HA looks good. If the sensor is updating the mqtt topic every 10 seconds, you’d have a lot more results than what you’re getting.
Have you tried connecting to your broker with a desktop mqtt application, subscribing to one of these topics, and verified it’s sending readings every 10secs? If possible, could you please post a log here, including timestamps.
Also, would you please post, or link your Arduino sketch?
I have set up an arduino and a nodemcu with the DHT22. Code I used is based on the BRUH multisensor. This way, the sensor will only publish a new value once there has been a change larger than X.
Seems to be more stable, sometimes the connection seems to drop, but not as much as before.
I added some code, publishing every minute or so if there has been no significant change.
@xstrex: I had no time to test your suggestions using MQTT.fx etc. I’ll try them asap. At the moment I checked the values in the database: my esp8266 sends strings “ERRTEMP”, “ERRHUM” etc. if there was an error reading the dht22 values. The graph shows those Strings as ‘0’. I expected that non integer values are ignored… I have to investigate more. Perhaps I’ll open an issue / feature request at github.
On the esp8266 side the simplest solution would be to not send anything ir there was an error. so only those values are sent to hass that are valid.
Yea I would try the MQTT.fx route, or another mosquitto subscription (even on the linux command line), the value from your sensor should never be ‘0’, even if the sensor was in an env that was actually ‘0’, it would still report something like ‘0.56’. Something isn’t right. If that was happening to me, I’d connect the esp8266 to the puter, and connect the Arduino console, and see why it’s reporting ‘0’. Let me know if you need any help.
You can find an example in one of the sample sketches included with the DHT library in the Arduino IDE of how to deal with a read error (which tends to happen fairly often with the DHT sensors, in my experience). Here’s a sample snippet I’m using from one of my projects:
void dht_read_publish() {
// Read values from sensor
float humidity = dht.readHumidity();
float tempC = dht.readTemperature();
// Check if there was an error reading values
if (isnan(humidity) || isnan(tempC)) {
Serial.print("Failed to read from DHT sensor; will try again in ");
Serial.print(dht_publish_interval_s);
Serial.println(" seconds...");
return;
}
// Convert celcius to fahrenheit
float tempF = tempC * 1.8 + 32;
}
The isnan test checks to see if either the reading for temp or humidity returned an error, and if so, exits the function early so you aren’t publishing garbage (I haven’t included the mqtt portion of this code, but after the read and convert to F is done I turn the values to JSON and publish over mqtt). I do the conversion to F manually rather than try to read F from the sensor since I figure that’s one less chance for the sensor to return an error value. Still, with a DHT11, I’m still seeing errors every 5-10 reads or so. I think it’s just the nature of the sensor.