AHT10 works very unreliable

[jeffreykog]

Operating environment/Installation (Hass.io/Docker/pip/etc.): Pip + virtualenv. Python 3.8.5, esphome 1.15.3

ESP (ESP32/ESP8266, Board/Sonoff): ESP8266, Wemos D1 Mini

ESPHome version (latest production, beta, dev branch): Latest, 1.15.3

Affected component: AHT10 -> https://esphome.io/components/sensor/aht10.html

Description of problem:
When starting the ESP, it correctly measures and reports temperature and humidity. After this first scan the values never change regardless of the update interval. It does report the value every update_interval seconds, but the value is always the same.
After exactly one hour, the text ATH10 Unrealistic humidity (0x0), retrying... is logged, followed by AHT10 is busy, waiting.... After that a new value is measured and reported. Then it follows the same loop again where it always reports the same value until an unrealistic value comes in.

I'm starting to think the module requires an explicit command to re-measure the value and if that isn't sent, the buffer wil keep containing the old value.

Problem-relevant YAML-configuration entries:

sensor:
  - platform: aht10
    temperature:
      name: "Werkkamer Jeffrey Temperatuur"
    humidity:
      name: "Werkkamer Jeffrey Luchtvochtigheid"
    # update_interval: 60s

i2c:
  sda: D2
  scl: D1
  scan: True
  id: bus_a

Logs (if applicable):

< ESP boots >
[19:04:11][I][app:105]: ESPHome version 1.15.3 compiled on Nov 16 2020, 19:03:50
[19:04:11][C][wifi:443]: WiFi:
[19:04:11][C][wifi:303]:   SSID: 'xxx'
[19:04:11][C][wifi:304]:   IP Address: 172.24.139.19
[19:04:11][C][wifi:306]:   BSSID: xxx
[19:04:11][C][wifi:307]:   Hostname: 'sensor_climate_werkkamer_jeffrey'
[19:04:11][C][wifi:311]:   Signal strength: -65 dB ▂▄▆█
[19:04:11][C][wifi:315]:   Channel: 6
[19:04:11][C][wifi:316]:   Subnet: 255.255.255.0
[19:04:11][C][wifi:317]:   Gateway: 172.24.139.1
[19:04:11][C][wifi:318]:   DNS1: 172.24.139.1
[19:04:11][C][wifi:319]:   DNS2: (IP unset)
[19:04:11][C][i2c:028]: I2C Bus:
[19:04:11][C][i2c:029]:   SDA Pin: GPIO4
[19:04:11][C][i2c:030]:   SCL Pin: GPIO5
[19:04:11][C][i2c:031]:   Frequency: 50000 Hz
[19:04:11][I][i2c:033]: Scanning i2c bus for active devices...
[19:04:11][I][i2c:040]: Found i2c device at address 0x38
[19:04:11][C][logger:185]: Logger:
[19:04:11][C][logger:186]:   Level: DEBUG
[19:04:11][C][logger:187]:   Log Baud Rate: 115200
[19:04:11][C][logger:188]:   Hardware UART: UART0
[19:04:11][C][aht10:117]: AHT10:
[19:04:11][C][aht10:118]:   Address: 0x38
[19:04:11][C][aht10:122]:   Temperature 'Werkkamer Jeffrey Temperatuur'
[19:04:11][C][aht10:122]:     Unit of Measurement: '°C'
[19:04:11][C][aht10:122]:     Accuracy Decimals: 2
[19:04:11][C][aht10:122]:     Icon: 'mdi:thermometer'
[19:04:11][C][aht10:123]:   Humidity 'Werkkamer Jeffrey Luchtvochtigheid'
[19:04:11][C][aht10:123]:     Unit of Measurement: '%'
[19:04:11][C][aht10:123]:     Accuracy Decimals: 2
[19:04:11][C][aht10:123]:     Icon: 'mdi:water-percent'
[19:04:11][C][captive_portal:169]: Captive Portal:
[19:04:11][C][ota:029]: Over-The-Air Updates:
[19:04:11][C][ota:030]:   Address: xxxx:8266
[19:04:11][C][ota:032]:   Using Password.
[19:04:11][C][api:095]: API Server:
[19:04:11][C][api:096]:   Address: xxxx:6053
[19:04:42][D][aht10:066]: AHT10 is busy, waiting...
[19:04:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.57526 °C with 2 decimals of accuracy
[19:04:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.65442 % with 2 decimals of accuracy
[19:05:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[19:05:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[19:05:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[19:05:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.57526 °C with 2 decimals of accuracy
[19:05:42][W][aht10:108]: Invalid humidity! Sensor reported 0% Hum
[19:05:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state nan % with 2 decimals of accuracy
[19:06:05][I][ota:046]: Boot seems successful, resetting boot loop counter.
[19:06:42][D][aht10:066]: AHT10 is busy, waiting...
[19:06:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.52376 °C with 2 decimals of accuracy
[19:06:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.69905 % with 2 decimals of accuracy
[19:07:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[19:07:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[19:07:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[19:07:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.52376 °C with 2 decimals of accuracy
[19:07:42][W][aht10:108]: Invalid humidity! Sensor reported 0% Hum
[19:07:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state nan % with 2 decimals of accuracy
[19:08:42][D][aht10:066]: AHT10 is busy, waiting...
[19:08:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.87318 °C with 2 decimals of accuracy
[19:08:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.05161 % with 2 decimals of accuracy
[19:09:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.87318 °C with 2 decimals of accuracy
[19:09:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.05161 % with 2 decimals of accuracy
[19:10:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.87318 °C with 2 decimals of accuracy
[19:10:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.05161 % with 2 decimals of accuracy

< Repeat this exact value for an entire hour >

[20:04:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.87318 °C with 2 decimals of accuracy
[20:04:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.05161 % with 2 decimals of accuracy
[20:05:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 25.87318 °C with 2 decimals of accuracy
[20:05:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 38.05161 % with 2 decimals of accuracy
[20:06:42][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[20:06:42][D][aht10:066]: AHT10 is busy, waiting...
[20:06:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 26.03531 °C with 2 decimals of accuracy
[20:06:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 37.77075 % with 2 decimals of accuracy
[20:07:42][D][sensor:092]: 'Werkkamer Jeffrey Temperatuur': Sending state 26.03531 °C with 2 decimals of accuracy
[20:07:42][D][sensor:092]: 'Werkkamer Jeffrey Luchtvochtigheid': Sending state 37.77075 % with 2 decimals of accuracy

< After an hour the same refresh happens >

Additional information and things you've tried:
I tried with multiple AHT10 modules and also with multiple D1 mini modules to rule a hardware problem out. It looks like an additional request is needed to the module. If any more information is needed i will provide it. I'm happy to help with any debugging

[probot-esphome]

aht10 source
aht10 issues
aht10 recent changes
_{^{(message by IssueLinks)}}

[G2G2G2G]

Unrelated to the code, but related to your AHT10 hardware:
DHT11/DHT22 are pretty much the worst devices you can get to read humidity, unless you go out of your way to find one even worse. (and imo should be removed from esphome with a warning to use SHT30 / SHT31 / SHT35 or BME280 etc)
Taking that into consideration, just get a SHT30 or even a bme280 and forget about those other sensors entirely... (be aware bme280 can self heat because it reads constantly, it is good to put it into sleep state)

Unsurprisingly their newer sensor the AHT10 is garbage as well. It has extremely slow reads and any batch of 5 will throw out random numbers same as the DHT11/DHT22. Don't just take my word for it though (I've only had hundreds of different sensors in lab environments) Here are some others:
https://forum.arduino.cc/index.php?topic=624204.15
https://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html

[kbx81]

Yeah...I know it doesn't solve the problem, but I more or less second what @G2G2G2G is saying here. I had a similar issue with the DHT22 where it would just randomly stop reporting data; I tried a different DHT22 module and, after a short while, same behavior. I'm not familiar with the AHT10 but I'd definitely recommend considering a different sensor if you can. I've used both the STHC3 and BME280 and they are much, much more reliable, consistent (device-to-device) and will generally give you more accurate data, especially for humidity, should you, say, be monitoring a filament storage/dry box where the humidity is supposed to be really low. 😉

[rlust]

Having the same issues with AHT10, reads once then repeats same reading.

[jeffreykog]

Thanks for the confirmation on a suspicion i already had that these sensors are not really good. If the issue of requesting data is not something that could be fixed in code, i think we should add a warning to the docs (to the AHT10, but also the DHT sensors) stating that, while they're cheap, the quality is not very good. Apart from the issue of not reporting data in a long time i also noticed the calibration on the sensors were way off. Not something that couldn't be fixed with a calibration table but that makes the entire process way more complex. I ordered some BME280 sensors to be done with the low quality sensors.

[G2G2G2G]

SHT30 & BME280 not much of a different price vs DHT22 when ordered from aliexpress/ebay china sellers. Only seems adafruit etc blow the price up.

As far as the "fixed with calibration table" unfortunately these sensors get more inaccurate with time so it's probably not even possible to calibrate them unless you do so monthly _

[fernplant]

Same issue. Tried multiple AHT10s all with the same result; will not update sampled value

[krunkel]

I just set the logging level to 'VERY_VERBOSE' to debug the problem and the aht10 started to send updated values every 60s.... Must be a timing issue...

[krunkel]

After determining that there was a timing issue, I changed the code in aht10.cpp (/opt/esphome/esphome/components/aht10)

static const uint8_t AHT10_DEFAULT_DELAY = 8; // ms, for calibration and temperature measurement
static const uint8_t AHT10_HUMIDITY_DELAY = 40; // ms
static const uint8_t AHT10_ATTEMPS = 3; // safety margin, normally 3 attemps are enough: 3*30=90ms

Was 5 for the DEFAULT_DELAY and 30 for HUMIDITY_DELAY.

I also altered the 'ESP_LOGVV' statements in ESP_LOGD statements.

This seems to fix the issue:

[20:35:34][D][aht10:062]: Attemps 0 at 59798
[20:35:34][D][aht10:066]: AHT10 is busy, waiting...
[20:35:34][D][aht10:062]: Attemps 1 at 59843
[20:35:34][D][aht10:082]: Answer at 59886
[20:35:34][D][sensor:092]: 'temp_garage': Sending state 22.70184 °C with 2 decimals of accuracy
[20:35:34][D][sensor:092]: 'vochtigheid_garage': Sending state 35.31160 % with 2 decimals of accuracy
[20:36:34][D][aht10:062]: Attemps 0 at 119806
[20:36:34][D][aht10:073]: ATH10 Unrealistic humidity (0x0), retrying...
[20:36:34][D][aht10:062]: Attemps 1 at 119852
[20:36:34][D][aht10:066]: AHT10 is busy, waiting...
[20:36:34][D][aht10:062]: Attemps 2 at 119896
[20:36:34][D][aht10:082]: Answer at 119938
[20:36:34][D][sensor:092]: 'temp_garage': Sending state 22.71824 °C with 2 decimals of accuracy
[20:36:34][D][sensor:092]: 'vochtigheid_garage': Sending state 35.63538 % with 2 decimals of accuracy

To be clear, the sensor is on my desk, temperature in the garage will be a bit lower ..

[tuononh]

+1 on this. I dont have this problem when testing with plain Arduino code with adafruit library as well as Tasmota. I even was able to pull data at 1s sampling rate.

Update: It works when I change log level to very verbose.

[weithhh]

Huge thanks for workaround with log level. Can confirm it working with ESP8266

I have a handful of AHTs, they can measure well enough for home use and very easy to get hand of. Would be kinda shame to rush for BMEs just because esphome doesn't handle them well.

Also I used them with some earlier versions of esphome, when driver was just merged, with ESP32. Sometimes they goofed measurements, but never had been stuck with same value for hours or until reset.

[G2G2G2G]

@weithhh just FYI don't "rush for BMEs" bosch's sensors are mostly for pressure, they self heat. SHT31, SHT35, SHT85 are sensors you'd want to switch to if any. (NEST uses SHT20 for example, $0.20 sensor for $300 unit) but they are the most accurate due to capacitive sensing and not resistive

[weithhh]

@G2G2G2G By rush for BMEs i mean rush for another 'reliable' hardware when there is already good enough on hand.

SHT are nice, but still aren't that easy to find in my local shops. AHT and BME have 1 hour time-to-buy characteristic:) vs month from china for something a bit less popular.

I think esphome should stay inclusive to popular hardware and handle it well. Sadly, don't quite have the time right now to fix it myself, when there is such a nice workaround.

[kbx81]

Can't argue with "use what's on-hand" and/or convenient.

But, for the record, I would shamelessly rush for a BME or SHT sensor. every. single. time. 😇

If you're buying new, yes, get what fits your budget and time table. That said, all other things being equal, personally I'd skip the DHT/AHT/AM sensors. In my experience, they just don't have the consistency that the other options do. 🙃