DHT11.ko (32-bit Bookworm Raspberry Pi OS with a 64-bit kernel) (raspberry pi 4b) #6220
Comments
|
I am having the same issue. After trying to fix the wiring, changing GPIO pins, it still wasn't resolving the issue. I gave up, and just wrote a python script that would read the dmesg and I would parse it myself. The code below only returns the humidity. WIth my sensor, I was getting values that would be 100+ the number. In your example, I would have values that would say 142 instead of just 42. There is logic in this code of if it's greater than 100, it will just ignore and try again. Program flow:
I know this is a hacky workaround. For my other application, I then simply imported and called this file to get the humidity import subprocess
import time
import re
def read_humidity():
try:
with open('/sys/bus/iio/devices/iio:device0/in_humidityrelative_input', 'r') as file:
humidity = file.read().strip()
return humidity
except Exception as e:
# Do not print the error
return None
def get_dmesg_messages():
try:
# Capture the output of dmesg
result = subprocess.run(['dmesg'], stdout=subprocess.PIPE, text=True)
# Return the output as a list of lines
return result.stdout.splitlines()
except Exception as e:
print(f"Error reading dmesg: {e}")
return []
def filter_dht11_messages(dmesg_lines):
dht11_messages = []
pattern = re.compile(r"dht11.*Don't know how to decode data:")
for line in dmesg_lines:
if pattern.search(line):
dht11_messages.append(line)
return dht11_messages
def extract_first_number(message):
match = re.search(r"decode data: (\d+)", message)
if match:
return int(match.group(1))
return None
def main():
last_dht11_message = None
last_extracted_number = None
while True:
# Read humidity
humidity = read_humidity()
if humidity is not None:
print(f"Humidity: {humidity}%")
# Wait for 0.1 seconds
time.sleep(0.1)
# Get the dmesg messages
dmesg_lines = get_dmesg_messages()
# Filter for DHT11-related messages
dht11_messages = filter_dht11_messages(dmesg_lines)
# Extract the most recent message if there are any new ones
if dht11_messages:
most_recent_message = dht11_messages[-1]
if most_recent_message != last_dht11_message:
last_dht11_message = most_recent_message
extracted_number = extract_first_number(most_recent_message)
if extracted_number is not None and extracted_number <= 100:
last_extracted_number = extracted_number
# Print the most recent extracted number
if last_extracted_number is not None:
print(f"Most recent extracted number: {last_extracted_number}")
else:
print("No valid number extracted from DHT11 messages.")
# Wait before the next iteration
time.sleep(2)
if __name__ == "__main__":
main() |
|
Am also seeing this error Software details lsb_release -a Hardware details
Gives this error % 50 of the time otherwise it gives a reasonable value as below Works some times dmesg dump |
|
Just an update, I gave the code above that decodes the dmesg, but after a few days that "workaround" wasn't working as dmesg was then reporting it wasn't getting anything at all. I ordered replacement sensors and when I swapped the existing sensor with a new one, this issue went away and I didn't need my workaround anymore |
|
I have the same problem. RPi 3B, Bookworm 64bit. dmesg: The /sys files: It seems that dtoverlay can't read nothing more than first two numbers from the bus. |
That's expected behaviour - the value is in milli-percent, 41000 means 41%
It's not the overlay doing the reading, it's the dht11 driver - the overlay just activates the driver. The driver itself is pure upstream code - we've not changed it at all. |
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: raspberrypi#6220 Signed-off-by: Phil Elwell <[email protected]>
|
The datasheet for the DHT11 could be clearer IMO, but I think the bytes between the main values should be treated as tenths of a percent or tenths of a degree. However, the driver expects them to be zeroes. Perhaps greater accuracy was added later, and perhaps only to the temperature value. There's a PR (#6454) that tries to interpret them as decimals, accepting any value between 0 and 9. If the values returned do happen to be zeroes then this patch will have no effect. If you want to try a test build, wait about 40 minutes for the auto-builds to complete, then run |
|
The trial builds are good to go now. |
pelwell
added
the
Close within 30 days
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
I've performed the update and it's working without errors now. Device tree files are readable in short interval: The DHT11 is made by ASAIR and it seems that it is enhanced variants of original DHT11 because in the documentation and on the body of the device is written temp range -20 - 60°C (not from 0 degrees), thus another question is how and if it will work properly on subzero temperatures. I'm going to freeze something in fridge and get the results. It definitely looks like the subzero temps are counted from 1 129 (-0.1), 1 130 (-0.2) and up (I have returned to mainline kernel because the dev kernel have no headers available which I need to compile other things). |
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: #6220 Signed-off-by: Phil Elwell <[email protected]>
Describe the bug
I think DHT11 module doesn't work with my kernel image
Steps to reproduce the behaviour
My aim is to read dht11 from the file system (kernel module)
Steps :
ls -l /sys/bus/iio/devices/iio:device0is :It shows
dmesg | tailisadafruit-circuitpython-dhtand it worked fine (following that article https://pimylifeup.com/raspberry-pi-dht11-sensor/)Device (s)
Raspberry Pi 4 Mod. B
System
cat /etc/issue:cat /etc/rpi-issue:vcgencmd version:uname -m:Logs
Additional context
It may be irrelevant. But I am also appended lcd and i2c-gepio-expander to my rpi device tree to work with the modules. Both of them work fine.
The text was updated successfully, but these errors were encountered: