Example of use?

[elf55]

I'd like to try using this, but I'm having trouble calling it correctly. An you provide an example of how to call it with appropriate parameters?

[kfricke]

Just noticed that the driver is not working on current versions of MicroPython. After adding support for newer machine API calls it does not read correct sensor values anymore. I will need to check tomorrow.

Basic usage example is:

import machine import sht31 i = machine.I2C(sda='Y10', scl='Y9') s = sht31.SHT31(i) s.get_temp_humi()

[elf55]

Thank you for responding -- and letting me know I'm not crazy. I'm not seeing the get_temp_humi method in sht31. I'm able to read the raw data from an sht31, but this did a lot of the housekeeping. I can work on the missing features, but it would be good to start with a working program.

[kfricke]

Which platform are you using, maybe the ESP8266? The symptom does sound like a memory error during import! In this case you can help yourself with using try to import the module as a precompiled bytecode. Be aware that this does need the most recent firmware. You may also need to recompile the module with each software upgrade (or St least whenever the compiler does change th bytecode implementation). This feature had just landed in most ports and is possibly not well documented. Try to search the MicroPython forum if you need assistance, please.

[elf55]

I am using the ESP8266 based Huzzah Feather. When I said I don't see the get_temp_humi method, I mean it's not in the code, not that it throws an error.

I can read and write to the sht31 using i2C methods:

>i2c.scan()                                                                                    
[68]                                                                                              
>i2c.readfrom(68,4)                                                                            
>b'\x00\x00\x81\xff'                                                                                     

and your sht31 code returns the following methods:

>import machine                                                                                
>import sht31                                                                                  
>i2c = machine.I2C(machine.Pin(5),machine.Pin(4),freq=10000)                                   
>sht31 = sht31.SHT31(i2c)                                                                      
>dir(sht31)                                                                                    
['_read_raw', '_send', '_map_cs_r', '__module__', 'read_f', '__init__', '__qualname__', '_recv', '
read_c', '_i2c', '_addr']  

and so trying your example of the get_temp_hum() method results in:

>sht31.get_temp_humi()                                                                         
Traceback (most recent call last):                                                                
  File "<stdin>", line 1, in <module>                                                             
AttributeError: 'SHT31' object has no attribute 'get_temp_humi'     

and attempting to execute the read_f method results in:

>sht31.read_f()                                                                                
Traceback (most recent call last):                                                                
  File "<stdin>", line 1, in <module>                                                             
  File "sht31.py", line 76, in read_f                                                             
  File "sht31.py", line 59, in _read_raw                                                          
  File "sht31.py", line 41, in _send                                                              
AttributeError: 'I2C' object has no attribute 'send'   

I can read/write from the sht31 using an identical Huzzah Feather running an Arduino sketch, so I don't think there is a hardware error. But if you think the version of micropython is the culprit, I may just elect to stick with using Wiring for this application. I was hoping to do some in-line computations with the humidity data and python would be far easier.

I have loaded esp8266-20160909-v1.8.4.bin, which is the current stable release.

I appreciate your support. I'm learning quite a bit more about micropython than I had anticipated.

[kfricke]

Sorry, but i had no clue, that the version on Github was that long out of date. This version still has a serious bug and does yield wrong sensor readings on my ESP8266s and pyBoards. Pleas give it another try regardless this fact. Probably my senor is faulty (it is my only SHT31 at the moment). Thanks!

[elf55]

I haven't done much more than download the new module and try it, but I have a problem as well. I'll play around with it and see if I can get around it. Here's the result:

>>> i2c = machine.I2C(machine.Pin(5),machine.Pin(4),freq=10000)                                   
>>> sht31 = sht31.SHT31(i2c) 
>>>sht31._raw_temp_humi()                                                                        
(65535, 65535)  
>>>sht31.get_temp_humi()                                                                         
Traceback (most recent call last):                                                                
  File "<stdin>", line 1, in <module>                                                             
  File "sht31.py", line 69, in get_temp_humi                                                      
  File "sht31.py", line 59, in _raw_temp_humi                                                     
  File "sht31.py", line 41, in _send                                                              
OSError: I2C bus error 

-Mike

[elf55]

Well look at this:

>>> sht.get_temp_humi(2,False,False)                                                              
(77.97571, 48.52979)

it even seems reliable in this mode. I tried several other modes and the sensor had to be power cycled each time. I haven't put a scope on it, but I'd guess the bus isn't quite stable. This is also with the default (400K??) i2c bus frequency.

[kfricke]

Interesting. I have bought only one of these sensors during sensor evaluation. Your initial problems that the bus gets stuck are reproducible on mine. Could you please provide me with a PR, so i can test my sensor health?

[elf55]

I'll test some more, the most consistent result is obtain by reducing the default resolution to medium (2) or low (3). Using the default high resolution generally messes up the bus and I need to power cycle the sensor. I only have one sensor on the bus at this point.

I'd like to continue to work on this, so appreciate the help. What is a PR??

[kfricke]

PR is the abbreviation of pull request here on GitHub. It is the common way of pushing back changes between forked repositories.

[elf55]

I haven't made any changes to your latest code. The only thing I did was set up the methods as described above and then played around with the parameters. The change that made the biggest difference is changing the first parameter on the get_temp_humi method from the default of "High" repeatability to "Medium" (2 value). Your method definition calls the first parameter "resolution", but i looking at the SHT31 data sheet it, Sensirion calls that register "repeatability".

get_temp_humi(self, resolution=R_HIGH, clock_stretch=True, celsius=True)

The "clock stretching" parameter doesn't seem to have much effect. I am a bit pressed for time to work on this for the next few days, but the notion I've got is that repeatability implies a longer time required to take the measurement and that perhaps the i2c lib isn't allowing enough time for the higher repeatability measurement. I would think that clock stretching would circumvent this, but again the parameter value doesn't seem to make much difference. I'll set up a test to hammer the sensor and see if I can watch the SDA line using a scope. In just manually executing get_tem_humi() calls, I do occasionally get an "I2C bus error", so finding an appropriate delay may be important. I also notice that the humidity register tends not to update until a subsequent call, although temp seems to be accurate. This is true if the wait between calls is 5 sec or 1 hour.

[Prekeshimo]

would this module work with an esp32?