logo elektroda
logo elektroda
X
logo elektroda

AHT10/AHT2X/AHT30 I2C Temperature & Humidity Sensor Driver in OpenBeken presentation

divadiow 4950 18
ADVERTISEMENT
  • Images of AHT10, AHT20, AHT21, and AHT30 sensors with visible pin labels.
    I noticed this pull request (PR) to add support for AHT10/AHT2x/AHT30 temperature and humidity sensors. We've seen the AHT30 in use in the TH01 device, but it is controlled by a TuyaMCU so does not need a driver for direct control by OpenBeken (OBK) in that instance. Same situation for the S09 with an AHT20.

    As the Github user NonPlayerCharacter posted in the pull request, this driver will be needed for devices where the user has decided to remove the TuyaMCU, and so control the sensor directly with OBK, or where a device does not come with an MCU at all and the Beken chip interfaces directly.

    Code: Text
    Log in, to see the code

    The sensors are made by Guangzhou Aosong Electronic Co. Ltd under the ASAIR brand name.

    The product pages for each:
    AHT10
    AHT15
    AHT20
    AHT21
    AHT25
    AHT30

    A comparison of the main specs:
    Code: Text
    Log in, to see the code


    The English datasheets for each are attached to this thread for reference.

    Onto some testing. I am using a NodeMCU dev board with a transplanted BK7231N based CB3S module. To save space, the AHTXX driver is disabled by default, ie it is not included in the general release builds. The binaries specific to the PR need to be flashed to make use of the driver. To download the special binaries navigate to https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/8769670483, login to Github, scroll to the bottom of the Summary page and download the zip file under the Artifacts section

    Screenshot of a Github page showing artifacts available for download.

    If flashing a BK7231N device that's already running OBK you'll need to use the OTA update method to flash the OpenBK7231N_1187_merge_4738dd2d9ba2.rbl file in the downloaded zip. If flashing by UART using Easy UART Flasher then use OpenBK7231N_QIO_1187_merge_4738dd2d9ba2.bin

    I used OTA method from the web application

    Screenshot of the OTA tab for the BK7231N chipset.

    After either method your build details on the OBK main page will be
    Screenshot of the device information page on NodeMCU with BK7231N chipset.

    and you'll see AHT2X driver options in the drop-downs on the module page
    Pin configuration for AHT2X sensors in the user interface.

    The AHT chips use the i2c protocol to communicate. The i2c (Inter-Integrated Circuit) protocol is a widely used communication method between components on a single integrated circuit, commonly used in microcontrollers and other digital electronics. It was developed by Philips Semiconductors (now NXP Semiconductors) in the early 1980s. i2c is particularly notable for its simplicity and effectiveness in managing communication between multiple integrated circuits over short distances using a minimum number of pins.

    You'll notice the AHT (and other i2c drivers in OBK) require an SDA and an SCL pin configuring. This is because i2c only requires two wires to transmit data between devices:
    SDA (Serial Data Line): This line is used for transmitting data between the master and slave devices.
    SCL (Serial Clock Line): This line is used by the master device to synchronize data transmission across the i2c bus.

    Additionally:
    -Each device on the i2c bus has a unique address which is used by the master device to communicate with a specific slave device.
    -The i2c protocol operates on a master-slave principle, where the master device initiates and controls the data transfer, and the slave devices respond to the master's requests.
    -Although it is a master-slave protocol, i2c supports multiple masters on the same bus, allowing more than one master to control the bus without interference through a built-in arbitration process.
    -All i2c transactions are synchronized with the clock pulses on the SCL line, making it a synchronous serial communication protocol.

    With that in mind, it looks like I will need to use P20 (SCL1) for AHT2X_SCL and P21 (SDA1) for AHT2X_SDA with the CB3S module I have for testing
    Pin diagram of the CB3S module with function labels.

    First, here are the AHT sensors I have to play with. They're all from Ali Express. AHT10, AHT20, AHT21 and AHT30. This means I will not be able to test AHT15 or AHT25.

    Images of AHT10, AHT20, AHT21, and AHT30 sensors with visible pin labels.

    Starting with the AHT10, I connect SDA to P21 (which maps to S3 on NodeMCU) and SCL to P20 (which maps to SK on NodeMCU). I am powering the AHTs with an external 3.3v so a common ground is established between the PSU, the sensor and the NodeMCU.

    AHT10 sensor module connected to NodeMCU board. NodeMCU development board connected with a sensor and power supply.

    To confirm the sensor is detected we can use OBKs Softi2c feature to detect the address of the device. Set SoftSDA and SoftSCL pins as appropriate. In my case:
    Screenshot of SoftSCL and SoftSDA settings on ports P20 and P21.

    in the web application log tab we check the i2c driver is started by entering command startdriver i2c then we can scan for i2c devices with command scani2c soft

    Screenshot of OBK configuration logs with i2c sensor detection

    We see in the log it detects and returns the correct address for the AHT10 - 0x38 (in decimal = 56). We should be able to swap to the AHT2X driver now. (note SCK = SCL). All the AHTXX tested will return 0x38 as their address.

    Screenshot of AHT2X pin configuration on NodeMCU.

    You'll need to save changes after swapping to reveal the second channel box for the SDA assignment. Ensure both channels differ from any other in use. After a reboot the AHT2X driver starts automatically and the temperature and humidity data is displayed as expected

    NodeMCU module configuration homepage with temperature and humidity data from AHT2X sensor

    Zipping through the remaining sensors:

    AHT20
    Temperature and humidity readings from the AHT2X sensor in user interface.

    AHT21
    Screenshot showing temperature and humidity readings from AHT2X sensor.

    AHT30
    Screenshot showing temperature and humidity readings from the AHT2X sensor.

    Apart from the AHT21 humidity, they all seem consistent. Perhaps the AHT21 will sort itself out if left untouched powered for a while. I also do not have any professional equipment to compare measurements against so not sure how accurate these readings are.

    Sticking with the AHT30 I'll demonstrate MQTT/HomeAssistant configuration and discovery. From the Config->Configure MQTT menu I'll set some test topic names, my HA server IP and the username/password credentials specific to my setup and click submit.

    MQTT configuration for AHT30 on the OpenBeken platform.

    Then under Config->Home Assistant Configuration->Start Home Assistant Discovery

    MQTT discovery in OpenBeken with Home Assistant discovery enabled

    A few seconds later the device tile should appear in HA complete with device name and the sensor readings

    Humidity and temperature readings on a NodeMCU CB3S device.

    Cool? Ranking DIY
    About Author
    divadiow
    Level 34  
    Offline 
    divadiow wrote 2786 posts with rating 482, helped 249 times. Live in city Bristol. Been with us since 2023 year.
  • ADVERTISEMENT
  • #2 21073652
    p.kaczmarek2
    Moderator Smart Home
    While all of these modules seem very cool, they miss one important feature - alert signal.
    Alert signal could be used to wake OBK when temperature reaches given threshold, thus help us save the battery.

    I have actually added one of such devices to OBK drivers, namely the MCP9808 . Here are links (com link will be updated soon):
    https://www.elektroda.pl/rtvforum/topic3988466.html
    https://www.elektroda.com/rtvforum/topic3988466.html
    Helpful post? Buy me a coffee.
  • #3 21073764
    divadiow
    Level 34  
    That'd be cool.

    Also, I wondered about this: https://github.com/openshwprojects/OpenBK7231T_App/pull/1187#issuecomment-2095717188

    How does a unified driver cater for the differences between the sensors and any differing operational recommendations?

    I recall seeing a pretty good discussion about the new AHT driver in a recent Tasmota PR recently that got me thinking about the differences. But maybe that was about detecting the exact AHT chip. I'll find it.

    Added after 31 [minutes]:

    maybe it was this https://github.com/arendst/Tasmota/discussions/20163

    anyway. OBK doesn't detect the device from i2c address.

    Interesting they calculate the dew point too from temp/hum
  • ADVERTISEMENT
  • #4 21074847
    p.kaczmarek2
    Moderator Smart Home
    divadiow wrote:

    Also, I wondered about this: https://github.com/openshwprojects/OpenBK7231T_App/pull/1187#issuecomment-2095717188

    How does a unified driver cater for the differences between the sensors and any differing operational recommendations?

    If I understand correctly, this is a question for the PR contributor, not for myself. Still, we can just check out the code...


    divadiow wrote:

    anyway. OBK doesn't detect the device from i2c address.

    Are you saying that I2C scanner does not pick up the address?
    You can try scanning with Arduino just to be sure:
    https://playground.arduino.cc/Main/I2cScanner/


    divadiow wrote:

    Interesting they calculate the dew point too from temp/hum

    So there is a formula to calculate dew point from just temp and humidity?
    Maybe we could integrate it into a separate OBK driver....

    Or, well, I checked and it seems easy, it could be done with OBK scripting
    Helpful post? Buy me a coffee.
  • #5 21074905
    divadiow
    Level 34  
    p.kaczmarek2 wrote:
    divadiow wrote:
    anyway. OBK doesn't detect the device from i2c address.


    I mean OBK doesn't scan for any i2c address then match driver for device automatically. my device i2c is detected fine.
    p.kaczmarek2 wrote:
    this is a question for the PR contributor, not for myself.

    yes that's cool. just linking this thread to that comment really.
  • #6 21074933
    p.kaczmarek2
    Moderator Smart Home
    The code you are referring to has I2C address hardcoded. It should be possible to adjust it to be taken from a variable or to rewrite the code so it can support multiple sensors if necessary.
    Screenshot of code in an editor, showing the definition of the I2C address for AHT2X.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #7 21075158
    insmod
    Level 23  
    I hardcoded the address, as from what i have seen, only AHT10 has the ability to change its address. And it still comes with 0x38 as default, and very few will have the tools | ability to change it. It is very easy to adapt the driver, but i honestly saw no need for it. As for polling interval, AHT2X_Cycle is just for that.
    Sorry for not having seen github comments, turned out i had notifications disabled.
  • ADVERTISEMENT
  • #8 21094116
    divadiow
    Level 34  
    p.kaczmarek2 wrote:
    While all of these modules seem very cool, they miss one important feature - alert signal.

    how easy would adding the alert feature be @insmod ? ;)
  • #9 21094192
    insmod
    Level 23  
    divadiow wrote:
    how easy would adding the alert feature be @insmod ? ;)

    Impossible, i believe. The sensors lack the alert pin. Where CHT83XX have it, AHT is NC.
  • #10 21094195
    divadiow
    Level 34  
    insmod wrote:
    Impossible, i believe. The sensors lack the alert pin. Where CHT83XX have it, AHT is NC.

    ah, fair enough!
  • #12 21422383
    maxim2002
    Level 13  
    I've tried this approach on one of aliexpress tuya generic th sensors.
    Close-up of a printed circuit board with an electronic module and wires.

    Did a build with ath2x and some mods to output the data from AHT2X_Measure if in trouble.
    Screenshot of C code snippet related to the AHT2X sensor.

    Boot seems solid, but I get following:
    Code: Text
    Log in, to see the code

    Some poking around pointed me into this datasheet, but it just got me confused more.
    Can't seem to reflect datasheet concepts in drv_aht2x, but I'm just a noob.
    Any help would be appreciated.
  • #13 21422646
    p.kaczmarek2
    Moderator Smart Home
    Which sensor do you have there, exactly?

    I am asking because I have a dev board here, with AHT20 from Aliexpress:
    Dev board with AHT20 sensor on a breadboard with connected wires.
    Dev board with various sensors on a breadboard.
    And it works just good, so it's fair to say that you have most likely a configuration error or a wrong sensor? We would need to check driver code, do you get any communication at all? Maybe wrong pins set?
    OpenW600 system interface with sensor readings from DHT11, BMP280, AHT2X, and DS1820, including toggle and configuration options.
    Helpful post? Buy me a coffee.
  • #14 21422703
    maxim2002
    Level 13  
    Board pix + log attached in previous post. It just sends back 18 38 20 00 00 00 all the time. Odd thing is that init and rest of stuff up to "Unrealistic humidity, will not update values" you have in drv_aht2x.c runs fine.
  • #15 21578703
    taggbricka
    Level 7  
    Is it possible to find a working OTA bin file for BK7231N and AHT30?
    The link in the original post seems to be broken.
  • #17 21579515
    taggbricka
    Level 7  
    >>21578725
    Will DRIVER_AHT2X work also for AHT30?
    I have got some AHT30 breakout boards an am considering buying some CB3S boards if they will work together.
    Tasmota presently has no support for AHT30.
  • Helpful post
    #18 21579691
    insmod
    Level 23  
    >>21579515
    Tasmota should work with AHT30. There is no difference between aht20/21/25 and aht30 code-wise.
    And with some tuning, like i've done on AHT2X driver in OBK, all AHT chips will work with the same driver (and not like in tasmota, where aht1x and aht2x are separate).
  • #19 21579968
    taggbricka
    Level 7  
    Great! I am not so familiar with openbeken.
    There was no AHT2x_SDA pin alternative present, so could not try that.
    startdriver AHT2x with SoftSDA on P7 and SoftSDA on P6 gave device timeout.
    But startdriver AHT2x 6 7 1 2; did work correctly.

Topic summary

The discussion revolves around the implementation of a driver for AHT10, AHT20, and AHT30 temperature and humidity sensors in OpenBeken (OBK). Users express interest in the potential for a unified driver that accommodates differences between these sensors, particularly in terms of operational recommendations. The need for an alert signal feature to optimize battery usage is highlighted, although it is noted that the AHT series lacks an alert pin, unlike the CHT83XX series. The conversation also touches on the hardcoding of I2C addresses in the driver, with the AHT10 being the only model capable of address changes. Suggestions for integrating dew point calculations into OBK are discussed, emphasizing the flexibility of the driver for various sensor configurations.
Summary generated by the language model.
ADVERTISEMENT