A full buffer was not returned. Try again. #33
Comments
|
same problem here with DHT11: Python 3.7.3, raspeberry pi 0, Linux raspberrypi 4.19.97+ #1294 |
|
Same here. I've implemented a try/raise with sleep of 2 seconds but it's a LOT less reliable than the old Python 2.7 library. |
|
This was also my problem and so back to the Adafruit_DHT library. Working 95% of the time on Python3 and Balena. |
|
I'm getting the same issue. I have the following: PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
Here is a sample of the output from my script: +-----------------------------------------------------------------+
[DHT-22] Connection to API refused. Starting in local mode.
[DHT-22] A full buffer was not returned. Try again.
[DHT-22] Sensor failure. Check wiring.
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
[DHT-22] Connection to API refused. Starting in local mode.
[DHT-22] A full buffer was not returned. Try again.
[DHT-22] Sensor failure. Check wiring.
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
[DHT-22] Connection to API refused. Starting in local mode.
[DHT-22] A full buffer was not returned. Try again.
[DHT-22] Sensor failure. Check wiring.
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
[DHT-22] Connection to API refused. Starting in local mode.
[DHT-22] Temperature: 20.0C Humidity: 53.7% Date/Time: 2020-05-01 23:41:14
[DHT-22] Queue size: 1
[DHT-22] Local Mode: False, Zip Code Exists: False
[DHT-22] Writing queue to file.
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
[DHT-22] Connection to API refused. Starting in local mode.
[DHT-22] Temperature: 19.9C Humidity: 53.0% Date/Time: 2020-05-01 23:41:25
[DHT-22] Queue size: 1
[DHT-22] Local Mode: False, Zip Code Exists: False
[DHT-22] Writing queue to file.
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
[DHT-22] Connection to API refused. Starting in local mode.
[DHT-22] A full buffer was not returned. Try again.
[DHT-22] Sensor failure. Check wiring.
+-----------------------------------------------------------------+This is with a 10 second interval between checks. The only message that isn't from my script is: |
|
Just ran into the same error. Any news on this one? |
|
FYI -- I just tried this on a Pi ZeroW -- it is intermittent for me as well-- This has been a common problem with the DTH22. BTW -- I also tried it on a Pi4 -- it appears to be respond better, but still some CRC errors in the brief test I ran, |
|
Same here, it intermittently fails File "/home/pi/.local/lib/python3.7/site-packages/adafruit_dht.py", line 252, in humidity |
|
I have run into the same problems. I have made some slight changes to the code and now I do not get these errors anymore. |
Added DHT11 and DHT22 Temp/Humidity Sensors to file. Added 'unit' parameter to 'sensors' section of YAML file. User can select Centigrade or Fahrenheit output. Note: There is currently an issue with these sensors and the adafruit_dht module "Error: A full buffer was not returned. Try again" Refn: adafruit/Adafruit_CircuitPython_DHT#33
|
I am having the same issues.. If I pop out to a python 2.7.2 environment, the old library works a charm...
Python 2 with the old library:
|
|
same here, after reboot nothing works anymore... I'm going to switch back to the old since this one seems to be not maintained either. |
|
Same problem |
|
same problems, i've tried for hours with no luck the old deprecated library (on latest python 3.7.3) works, even though i get plenty of misreads and have a 'retry' loop every 3 seconds to eventually get a good read, but circuitpython is total bllcks, it gives the following messages in a random order: sometimes at the start it says: 'unable to set line 23' to input (the old library works just fine on this pin) then: Timed out waiting for PulseIn message. Make sure libgpiod is installed. - FYI: latest libgpiod2 IS installed) i rebooted the pi zero, and whoopee started to get the occasional reading inbetween 10-20 failures, used ctrl-c to cancel, re-tried a minute later, and then no readings at all, just error messages. to deprecate a working library replacing it with a buggy non-working one leaves me (almost) speechless, and i'm unlikely to consider adafruit software or products for my projects, i think i'll look elsewhere if it aint sorted soon. btw my pi is fully upgraded and updated GL Bob |
|
same here ---Adafruit_CircuitPython_DHT does not work in 80% of the cases |
|
Some more anecdata. From my logs - successful reads are followed by 10 second sleep, failed reads are followed by 0.2 secs sleep. Likewise, the old non-circuitpython library works fine, but the new one is unreliable. Possibly the old library hid the unreliability of the DHT22 itself? @jerryneedell @dherrada @kattni @ladyada - As major contributors and/or representatives of Adafruit, could you comment on this thread? I'm interested to know if this is by design / fixable / on the roadmap etc. Thanks |
This appears to be the case: https://github.com/adafruit/Adafruit_Python_DHT/blob/master/Adafruit_DHT/common.py#L83-L98 If you used The underlying pulse code of the old library is written in C here: https://github.com/adafruit/Adafruit_Python_DHT/blob/master/source/Raspberry_Pi/pi_dht_read.c I'm not sure how pulses are counted via Blinka. @makermelissa would know.
My API design preference is to not hide unreliability because it allows the user to decide what to do. It's simple enough to rewrite It's important to note this library is shared with CircuitPython and problems with this library would show with it as well. Linux isn't great for real-time so this is more likely an issue with the underlying pulse tracking on Linux. |
quite possibly indeed, but at least you can get readings to some degree, which i'm finding almost impossible in the new circuitpython version. I think i stumbled across a library written by someone else that said it worked fine with the DHT22, so maybe i'll try find it again when i get the opportunity and give it a spin. regards. |
|
I thought it was just me! |
|
I have the same issues as people on this thread for Pi Zero and Pi 3 Model
B. For those cases I used the old library. This does work on my Pi 4
though. Hope that data point helps.
On Sun, Nov 1, 2020 at 9:49 PM shawnerz ***@***.***> wrote:
I thought it was just me!
I spent over 8 hours today (Sunday) trying to figure out what went wrong.
I switched between a Pi Zero 1.2 and a Pi Zero W 1.1. I tried a 1K resistor
(as mentioned in the manufacture's datasheet) and a 10K resistor (in the
Adafruit and Pimylifeup pages. I didn't try 4.7k). I tried sample rates as
slow as 30 seconds. I'm getting about a 95% failure rate.
In the process, I heat damaged a SD card (from soldering too close to it)
and had to reload the OS and what I had done to a new SD card. Nothing
seemed to work.
Interestingly enough, 2 months ago (early September), I used an old Pi
Zero ver. 1.2 (no wi-fi), a DHT22, and 10K resistor to monitor room
temperature. I am getting about a 75% success rate.
Because the DHT22's are so cheap, I bought 6 on Amazon. I'm using the ones
from that purchase. I duplicated the set up, and getting about a 95%
failure rate. *Something* had to have changed in the code base from
September.
It just so happens I am going to that site tomorrow (Monday). I'm going to
image that SD card and run it here at home to see if I get different
results.
-Shawn
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABWK533DUCIP4XTMZU2TX3SNZB6XANCNFSM4KVQQWVQ>
.
--
…-Andrew
|
|
Thank you for your response! How do I get and install the old library? |
|
Thank you very much. I will install it tonight.-Shawn
On Mon, Nov 2, 2020 at 1:38 AM, fniko<notifications@github.com> wrote:
@shawnerz https://github.com/adafruit/Adafruit_Python_DHT
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Oh, I forgot to leave an update. |
|
I changed the print to show the buffer size that it gets and on my Zero W and I'm getting between 30-65 instead of the required 80+. Maybe my sensor is even slower than most. I switched to the deprecated library and that works fine. I wonder if 80 is just too high an expectation. |
|
I don't know. All I know is the MCP9808 responds every time. |
|
@shawnerz - in a process of validating whether it is the sensor being broken or maybe PEBCAK - I check with mine too haha I used PicoScope though (PS5444D) with x10 probe and pulse-width trigger 😄
This data should represent something ~ 21.5*C and 55.6% humid. Anyway, my story was - first figuring out what is the mapping for About 20% it is correct, other times it flickers between the mentioned message, "Checksum did not validate. Try again." and occasionally even "DHT sensor not found, check wiring" - which makes me think that maybe the connection on the board might be wacky - thresholds are not met appropriately and the information is misinterpreted. 🤷 Good luck :) |
|
Experienced the same error and issue was that I have been using bitbanging instead of PulseIO (CircuitPython) because CircuitPython was not installed yet on my RPi Zero W. I followed https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/installing-circuitpython-on-raspberry-pi with an additional “pip3 install sysv-ipc” (no idea why missing ...) and now my DHT22 works perfectly fine. Bitbanging is likely more of a last resort nevertheless clearly not working well - I got about 60 of the 81 required pulses when bitbanging was used. |
|
I'm getting the same errors
I used to use the old library, but as it was deprecated I decided to switch to this one. |
|
Same error here, continuously |
|
Similar issues here, with a Pi Zero W. |
|
I'm having similar issue "A full buffer was not returned. Try again.." with Pi Zero WH and the DHT22, reading through these comments, there doesn't seem to be a definitive answer yet on how to fix. My software setup seems to be good using python3, a Blinka test is good, the wiring i have checked and is good. So what can i try now.... and troubleshoot further steps I could try. Thanks for any suggestions. |
|
As I understand it, there is something wrong in Adafruit's library. I don't know what it is. The transmit and receive waveforms look good on a 'scope. |
|
Confirmed problem. Works okish on the Pi4 and I can get readings. About a 95%+ failure rate on the Pi zero W. I let some code run on the pi zero all night and it never once was able to get a reading. Exact same code on Pi 4 is able to get a reading 50% of the time. Other DHT libraries work perfectly fine so it must be a software issue. Hope there is a discovery on the issue soon as we are now reverting to old / other libraries in the meantime for better stability. |
|
Can confirm as well the older libraries work better. |
I did the same test late last week with same results. I concur, it has to be a software issue. |
|
Same problem here. Unfortnetly the old library did not work anymore on a fresh pi light install. |
|
Thanks @m-keller for: Installing this package fixed the problem for me. |
|
I had the same issues when trying to read from a sensor on a pi zero however when using the pi zero 2w it works . I used the same SD card for both tests |
|
That's very interesting. If you query the sensor every 10 seconds for 10 minutes, what is the success rate? |
|
From https://learn.adafruit.com/circuitpython-on-google-coral-linux-blinka/faq-troubleshooting
Installing |
|
I installed |
|
I understood the old library used a retry function, so I use a simple retry function one myself. Seems to do the job ok; |
|
It seems like adding the |
|
I have adopted the script from @ricdijk, because the loop stops after the 2nd try (it doesn't raise an exception, and the values are type none). The trick is to reinit the sensor (exit on exception an recreate in the loop): |
|
Two years late, still ran into the same problem. Following olastor's suggestion and using "use_pulseio = True" (i.s.o False, as stated in most manuals) worked for me. |
|
I've switched temp sensors, so it's no longer an issue for me. But, in my next project, I'll add it back in. I like being able to track humidity.Thanks,-Shawn
Yahoo Mail: Search, Organize, Conquer
On Fri, Mar 29, 2024 at 11:30 AM, ***@***.***> wrote:
Two years late, still ran into the same problem. Following olastor's suggestion and using "use_pulseio = True" (i.s.o False, as stated in most manuals) worked for me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
and others
Hi,
using Raspberry Pi Zero with DHT11 sensor and I am observing this issue:
"A full buffer was not returned. Try again." after running
dht_simpletest.py.I edited values to match DHT11 and P4 (i use)
I tested the sensor using the old library and it works (90+ % succ read rate), but using the new library I can barely make one successful request.
Also I tried to increase sleep period to 5 sec with no result.
How should I troubleshoot this?
The text was updated successfully, but these errors were encountered: