Breakout boards are available from Adafruit.
This Sparkfun board has an Si7021 chip which, from a look at the datasheet, appears to be a clone of the HTU21D. The Sparkfun prduct ID is the same as boards which I own: mine have HTU21D chips.
This driver was derived from the synchronous Pyboard-specific driver
here. It is
designed to be multi-platform and uses asyncio
to achieve asynchronous (non-
blocking) operation. The driver maintains temperature
and humidity
bound
variables as a non-blocking background task. Consequently reading the values is
effectively instantaneous.
Copy the as_drivers/htu21d
directory and contents to the target hardware.
Copy primitives
and contents to the target.
Files:
htu21d_mc.py
The asynchronous driver.htu_test.py
Test/demo program.
This runs on any Pyboard or ESP32. for other platforms pin numbers will need to be changed.
Pin | Pyboard | ESP32 |
---|---|---|
gnd | gnd | gnd |
Vin | 3V3 | 3V3 |
scl | X9 | 22 |
sda | X10 | 23 |
On the Pyboard D the 3.3V supply must be enabled with
machine.Pin.board.EN_3V3.value(1)
This also enables the I2C pullups on the X side. To run the demo issue:
import as_drivers.htu21d.htu_test
This provides a single class HTU21D
.
Constructor.
This takes the following args
i2c
(mandatory) An initialised I2C bus instance.read_delay=10
. The frequency (secs) at which data values are updated.address=0x40
I2C address of the chip.
Public bound values
temperature
Latest value in Celcius.humidity
Latest value of relative humidity (%).
Initial readings will not be complete until about 120ms after the class is
instantiated. Prior to this the values will be None
. To avoid such invalid
readings the class is awaitable and may be used as follows.
import asyncio
from machine import Pin, I2C
from as_drivers.htu21d import HTU21D
htu = HTU21D(I2C(1)) # Pyboard scl=X9 sda=X10
async def main():
await htu # Wait for device to be ready
while True:
fstr = 'Temp {:5.1f} Humidity {:5.1f}'
print(fstr.format(htu.temperature, htu.humidity))
await asyncio.sleep(5)
asyncio.run(main())
Thermal inertia of the chip packaging means that there is a lag between the
occurrence of a temperature change and the availability of accurate readings.
There is therefore little practical benefit in reducing the read_delay
.