The update of the LoPy causes bugs on my taking value on the DHT22



  • Hi, I have recently updated the LopY and when I want to get the DHT22 sensor temperature I have an error (I never quite the while beacause ), the program always finds the same value and I tested the program on an old version (1.0.0.b1) it works :s. Someone would know where the problem might come from?

    The old version :

    (sysname='LoPy', nodename='LoPy', release='1.0.0.b1', version='v1.8.6-237-g9d21f17 on 2016-12-15', machine='LoPy with ESP32')
    

    My current version :

    (sysname='LoPy', nodename='LoPy', release='1.6.10.b1', version='v1.8.6-556-g989d5ac9 on 2017-03-30', machine='LoPy with ESP32', lorawan='1.0.0')
    

    My main.py :

    from machine import Pin
    from dht import DHT22
    
    #Initialisation du capteur
    dht_pin=Pin('P22', Pin.OPEN_DRAIN)
    dht_pin(1)
    
    #Aquisition des données du capteur
    temp = -350
    while temp < -300 :
        temp, hum = DHT22(dht_pin)
    
    #Transfomation de celles-ci
    temp_str = '{}.{}'.format(temp//10,temp%10)
    hum_str = '{}.{}'.format(hum//10,hum%10)
    
    #Affichage
    print('T'+temp_str+'H'+hum_str)
    

    My dht.py

    from machine import enable_irq, disable_irq
    import time
    
    def getval(pin) :
        ms = [1]*300
        pin(0)
        time.sleep_us(20000)
        pin(1)
        irqf = disable_irq()
        for i in range(len(ms)):
            ms[i] = pin()      ## sample input and store value
        enable_irq(irqf)
        return ms
    
    def decode(inp):
        res= [0]*5
        bits=[]
        ix = 0
        try:
            if inp[0] == 1 : ix = inp.index(0, ix) ## skip to first 0
            ix = inp.index(1,ix) ## skip first 0's to next 1
            ix = inp.index(0,ix) ## skip first 1's to next 0
            while len(bits) < len(res)*8 : ##need 5 * 8 bits :
                ix = inp.index(1,ix) ## index of next 1
                ie = inp.index(0,ix) ## nr of 1's = ie-ix
                bits.append(ie-ix)
                ix = ie
        except:
            return([0xff,0xff,0xff,0xff])
    
        for i in range(len(res)):
            for v in bits[i*8:(i+1)*8]:   #process next 8 bit
                res[i] = res[i]<<1  ##shift byte one place to left
                if v > 2:
                    res[i] = res[i]+1  ##and add 1 if lsb is 1
    
        if (res[0]+res[1]+res[2]+res[3])&0xff != res[4] :   ##parity error!
            res= [0xff,0xff,0xff,0xff]
    
        return(res[0:4])
    
    def DHT11(pin):
        res = decode(getval(pin))
        temp = 10*res[0] + res[1]
        hum = 10 * res[2] + res[3]
        return temp, hum
    
    def DHT22(pin) :
        res = decode(getval(pin))
        hum = res[0]*256+res[1]
        temp = res[2]*256 + res[3]
        if (temp > 0x7fff):
            temp = 0x8000 - temp
        return temp, hum


  • @robert-hh

    Ok thank you (I use the good pin and all of your code).



  • @bessonf OK. Sometimes the read fails, and then you get -32768, 6553,5. That's a problem of the esp32 timing.



  • @bessonf Did you take a) my code literally, or did you b) just copy in the functions getval() and decode().
    In case of a) my code uses a different Pin
    in case of b) should work I'l check later. You could print the bits array in decode(), how the distributions of values is. There shoudl be two groups of values, and _LIMIT must be chosen as the median between those.



  • I updated it again and tested your code and it works. Maybe when the last update there was a bug or something it was incorrectly installed.



  • @robert-hh
    That work but i have only 0.0 and 0.0 on response and no error message.

    0.0 0.0
    

    And if i put a while loop for haven't 0.0 0.0 i have that :

    object not in sequence 0 0
    -3277.3 6553.5


  • @bessonf There was another post about that, and during the discussion I modified the code here https://forum.pycom.io/topic/948/dht-11-sensor-always-return-same-value/14 , my most recent response, which I have tested with 1.6.9.b1 and an DHT22. I could test that this evening with 1.6.10b1.



  • @bucknall

    I never leave the while because the value found is always the same and false (-32767). This is not really an error or an exception.


  • administrators

    Hi @bessonf,

    What is the error you are getting?


Log in to reply
 

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.