esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 35 forks source link

AHT10 works very unreliable #1635

Closed jeffreykog closed 2 years ago

jeffreykog commented 3 years ago

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[bot] commented 3 years ago

aht10 source aht10 issues aht10 recent changes (message by IssueLinks)

G2G2G2G commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

jeffreykog commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

krunkel commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

+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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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. 🙃

krunkel commented 3 years ago

Resolved by adding "delay_microseconds_accurate(4);" on line 63. (Pending pull request)

jesserockz commented 3 years ago

Can people please test esphome/esphome#1498 and comment there if it works for you.

Install a secondary (Beta or dev) ESPHome HA addon and apply this config to the addon:

esphome_version: "krunkel:dev"
G2G2G2G commented 3 years ago

@weithhh yea I agree with using the most popular hardware. Which would be Switzerland's Sensirion (SHT) used in virtually every digital equipment for temp/humidity that doesn't need pressure (Bosch (BME/P) used there instead) lmao. :^)

For the future I'd recommend buying several now and using later. I wish someone told me that years ago, I went through many many stages of regretting sensors in the past 10-15 years.

varhub commented 3 years ago

Similar behavior. Sensor values are valid meanwhile dashboard is performing logging. After some minutes, values get frozen and no more update is sent to HA. Normally, open web logging forces a new update, but its a futile approach.

Now I'm testing krunkel:dev with custom frequency and amount of warnings is not better:

sensor:

Does delay_microseconds_accurate(4), AHT10_DEFAULT_DELAY and other delays depends on i2c clock speed?

PS: my only long-term working config was by chance with frequency:200khz and including sensor wifi rssi. Without rssi sensor or with additional uptime one temperature gets frozen. PS2: by now I will try to overcome busy and unrealistic errors tweaking c++ values.

quizzical86 commented 3 years ago

Just to flag that my log is also full of these messages about unrealistic values and the sensor being busy:

[09:33:19][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying...
[09:33:19][D][aht10:067]: AHT10 is busy, waiting...
[09:33:19][D][sensor:117]: 'Room Temperature': Sending state 24.61529 °C with 2 decimals of accuracy
[09:33:19][D][sensor:117]: 'Room Humidity': Sending state 69.34834 % with 2 decimals of accuracy

But it seems harmless as the values are getting sent.

mahlernim commented 3 years ago

I am using an AHT20 and ran into the same issue. The following changes made the sensor report new values every cycle without any wierd messages.

Padm59 commented 2 years ago

I am using an AHT20 and ran into the same issue. The following changes made the sensor report new values every cycle without any wierd messages.

  • change i2c frequency to 200kHz (ESPHome Default is 50kHz, and datasheet requires 100 to 400kHz)
  • increase delay values in aht10.cpp: AHT10_DEFAULT_DELAY = 8 and AHT10_HUMIDITY_DELAY = 40
  • did not change log level to VERY_VERBOSE

Hey @mahlernim, how did you change the delay values and where is the aht10.ccp? I am also getting all the time the same values.

mahlernim commented 2 years ago

Hi @Padm59 I made a video about this issue https://youtu.be/4L3bv0sM8ag However, this may not work due to the recent breaking updates.

Padm59 commented 2 years ago

It's unfortunately not working anymore, and I really have no clue why (btw great video). About the breaking changes, I did not find something that is related to this problem. What happened? I changed some other things in the file for troubleshooting. Changed all log outputs to log lvl ERROR.

This happened with multiple different timings, from yours to 100ms both.

[17:34:06][D][api.connection:736]: Home Assistant 2021.10.4 (192.168.1.200): Connected successfully [17:34:08][E][aht10:075]: Attempt 0 at 17314 [17:34:08][E][aht10:106]: Answer at 17517 [17:34:08][D][sensor:113]: 'Phil Temperatur': Sending state 20.12558 °C with 2 decimals of accuracy [17:34:08][D][sensor:113]: 'Phil Luftfeuchtigkeit': Sending state 60.49147 % with 2 decimals of accuracy [17:34:28][E][aht10:075]: Attempt 0 at 37314 [17:34:28][D][aht10:097]: ATH10 Unrealistic humidity (0x0), retrying... [17:34:28][E][aht10:075]: Attempt 1 at 37518 [17:34:29][E][aht10:106]: Answer at 37720 [17:34:29][D][sensor:113]: 'Phil Temperatur': Sending state 20.12863 °C with 2 decimals of accuracy [17:34:29][D][sensor:113]: 'Phil Luftfeuchtigkeit': Sending state 60.47087 % with 2 decimals of accuracy [17:34:48][E][aht10:075]: Attempt 0 at 57314 [17:34:48][D][aht10:097]: ATH10 Unrealistic humidity (0x0), retrying... [17:34:48][E][aht10:075]: Attempt 1 at 57518 [17:34:49][E][aht10:106]: Answer at 57720 [17:34:49][D][sensor:113]: 'Phil Temperatur': Sending state 20.12253 °C with 2 decimals of accuracy [17:34:49][D][sensor:113]: 'Phil Luftfeuchtigkeit': Sending state 60.32696 % with 2 decimals of accuracy [17:35:08][E][aht10:075]: Attempt 0 at 77314 [17:35:08][D][aht10:097]: ATH10 Unrealistic humidity (0x0), retrying... [17:35:08][E][aht10:075]: Attempt 1 at 77518 [17:35:09][E][aht10:106]: Answer at 77720 [17:35:09][D][sensor:113]: 'Phil Temperatur': Sending state 20.12291 °C with 2 decimals of accuracy [17:35:09][D][sensor:113]: 'Phil Luftfeuchtigkeit': Sending state 60.46085 % with 2 decimals of accuracy

The fault has to be in the for loop and I don't get it.

@mahlernim is it still working for you and have you any tips?

Padm59 commented 2 years ago

Hello @jesserockz I think this Issue should be reopened. The Component is not working as intended and we should figure out why.

I again tested with multiple different timings and did not get it to work. The only thing working currently for me is changing loglevel to VERY_VERBOSE. Now correct values are measured. Nevertheless ATH10 Unrealistic humidity (0x0), retrying... prints every time after the first measurement. See yourself:

...

[18:50:51][VV][i2c.arduino:121]: 0x38 TX 00AC3300
[18:50:51][VV][aht10:075]: Attempt 0 at 2443585
[18:50:51][VV][i2c.arduino:121]: 0x38 TX 00
[18:50:51][VV][i2c.arduino:097]: 0x38 RX 199992A59693     [[[[[[[THIS PART IS DIFFERENT]]]]]]]]
[18:50:51][VV][aht10:106]: Answer at 2443671
[18:50:51][V][sensor:062]: 'Phil Temperatur': Received new state 19.852257

...

[18:51:11][VV][scheduler:152]: Running interval 'update' with interval=20000 last_execution=2443581 (now=2463581)
[18:51:11][VV][i2c.arduino:121]: 0x38 TX 00AC3300
[18:51:11][VV][aht10:075]: Attempt 0 at 2463586
[18:51:11][VV][i2c.arduino:121]: 0x38 TX 00
[18:51:11][VV][i2c.arduino:097]: 0x38 RX 190000059693
[18:51:11][E][aht10:097]: ATH10 Unrealistic humidity (0x0), retrying...
[18:51:11][VV][i2c.arduino:121]: 0x38 TX 00AC3300
[18:51:11][VV][aht10:075]: Attempt 1 at 2463675
[18:51:11][VV][i2c.arduino:121]: 0x38 TX 00
[18:51:11][VV][i2c.arduino:097]: 0x38 RX 199A0DA596C3
[18:51:11][VV][aht10:106]: Answer at 2463760
[18:51:11][V][sensor:062]: 'Phil Temperatur': Received new state 19.861412

...

[18:51:31][VV][i2c.arduino:121]: 0x38 TX 00AC3300
[18:51:31][VV][aht10:075]: Attempt 0 at 2483585
[18:51:31][VV][i2c.arduino:121]: 0x38 TX 00
[18:51:31][VV][i2c.arduino:097]: 0x38 RX 1900000596C3
[18:51:31][E][aht10:097]: ATH10 Unrealistic humidity (0x0), retrying...
[18:51:31][VV][i2c.arduino:121]: 0x38 TX 00AC3300
[18:51:31][VV][aht10:075]: Attempt 1 at 2483675
[18:51:31][VV][i2c.arduino:121]: 0x38 TX 00
[18:51:31][VV][i2c.arduino:097]: 0x38 RX 199A950596F7
[18:51:31][VV][aht10:106]: Answer at 2483760
[18:51:31][V][sensor:062]: 'Phil Temperatur': Received new state 19.871330

...

As you can see when I start the log, the ATH10 Unrealistic humidity (0x0), retrying... is not showing and everything is going as it should be. The second and all following updates have the problem and without the VERY_VERBOSE loglevel the values of the measurements are not changing. So what exactly is changing when you change the loglevel? I guess it must have something to do with the timing of some events (I changed the delay in the file multiple times and tested also several I2C freq. no effect other than with to small delays, the sensor is still busy) maybe something internal in the write and reed process.

I also referenced with other libraries implementing the aht10 and communication with the sensor and all the commands being sent are the same, so the general implementation should be right. One thing, I am not sure about is the different operation modes of the sensor (https://github.com/enjoyneering/AHT10/blob/66c70920bd248f703a2c09130b3e1f628d73944d/src/AHT10.h#L63-L65), also the data sheet is very unclear.

I also can confirm that my sensors are working because I used them in earlier projects with above mention Arduino libraries on the esp without esphome.

Hope someone can help with this because this is the first time for me to see how esphome is working internally and I don't have much experience.

Thanks a lot in advance!

mahlernim commented 2 years ago

@Padm59 Can you try loading my version of external component? AHT20 is working well with me at the moment. My ESPHome version is 2021.10.3, Core version is 2021.10.6, OS version is 6.5, running HASSOS on a Raspberry Pi 4B

external_components:
  - source:
      type: git
      url: https://github.com/mahlernim/esphome
      ref: dev
    components: [ aht10 ]
Padm59 commented 2 years ago

@mahlernim unfortunately it doesn't help (timings of yours are good because no busy messages). Still exactly the same problem. I am also running the latest versions on a pi 4b and I even tested with 200 kHz 100 kHz and 400 kHz. Nothing changed, exact same log.

The weird thing is that it only works for me when VERY_VERBOSE logging is active. Then I get correct measurements, but the Unrealistic humidity (0x0) is still cumming. Otherwise, it spits every time the same temp and humid.

@jesserockz do you have any idea why this is not working?

@jeffreykog is it still working for you?

jeffreykog commented 2 years ago

@Padm59 Thanks. I have switched to BME280 sensors for stability and have been very happy with those. So unfortunately i can't tell you about the stability on AHT10 for me.

krunkel commented 2 years ago

In the last esphome release, the ath10 component was indeed unreliable (again) (no new measurements after initial one). I removed line 76-82 from aht10.cpp. after this the aht10 works fine. I will do a pull request to change this.

void AHT10Component::update() { if (!this->write_bytes(0, AHT10_MEASURE_CMD, sizeof(AHT10_MEASURE_CMD))) { ESP_LOGE(TAG, "Communication with AHT10 failed!"); this->status_set_warning(); return; } uint8_t data[6]; uint8_t delay_ms = AHT10_DEFAULT_DELAY; if (this->humiditysensor != nullptr) delay_ms = AHT10_HUMIDITY_DELAY; bool success = false; for (int i = 0; i < AHT10_ATTEMPTS; ++i) { ESP_LOGVV(TAG, "Attempt %d at %6u", i, millis()); //delay_microseconds_accurate(4);

//uint8_t reg = 0;
//if (this->write(&reg, 1) != i2c::ERROR_OK) {
//  ESP_LOGD(TAG, "Communication with AHT10 failed, waiting...");
//  continue;
//}
delay(delay_ms);
if (this->read(data, 6) != i2c::ERROR_OK) {
  ESP_LOGD(TAG, "Communication with AHT10 failed, waiting...");
  continue;
}
Padm59 commented 2 years ago

Thank you all for your help, works near perfectly now. Now there is only the measurement delay problem left: AHT10 is busy, waiting...

Lets change both, default and humidity delay to the 75ms minimal measurement time according to the data sheet, Maybe even make it one delay for both to simplify code. @krunkel

With these changes I can confirm measurements are working without errors.

CyanoFresh commented 2 years ago

Hi. If I add filters: median or etc it logs AHT10 is busy, waiting... on every read. If I remove filters no message is showing

quizzical86 commented 2 years ago

I can't get the AHT10 to work. I'm getting the same errors as have been listed before in this issue:

[23:46:00][D][aht10:083]: AHT10 is busy, waiting...
[23:46:00][D][aht10:090]: ATH10 Unrealistic humidity (0x0), retrying...
[23:46:00][D][aht10:083]: AHT10 is busy, waiting...
[23:46:00][E][aht10:105]: Measurements reading timed-out!

Once I was able to get initial readings (which were crazy, 150 degrees Celsius and 96% humidity) but these were not updated afterwards.

I've tried everything I read about, including:

Nothing helped. Anything else I could try?

Padm59 commented 2 years ago

I use this in my custom external componenet:

// Implementation based on:
//  - AHT10: https://github.com/Thinary/AHT10
//  - Official Datasheet (cn):
//  http://www.aosong.com/userfiles/files/media/aht10%E8%A7%84%E6%A0%BC%E4%B9%A6v1_1%EF%BC%8820191015%EF%BC%89.pdf
//  - Unofficial Translated Datasheet (en):
//  https://wiki.liutyi.info/download/attachments/30507639/Aosong_AHT10_en_draft_0c.pdf
//
// When configured for humidity, the log 'Components should block for at most 20-30ms in loop().' will be generated in
// verbose mode. This is due to technical specs of the sensor and can not be avoided.
//
// According to the datasheet, the component is supposed to respond in more than 75ms. In fact, it can answer almost
// immediately for temperature. But for humidity, it takes >90ms to get a valid data. From experience, we have best
// results making successive requests; the current implementation makes 3 attempts with a delay of 30ms each time.

#include "aht10.h"
#include "esphome/core/log.h"
#include "esphome/core/hal.h"

namespace esphome {
namespace aht10 {

static const char *const TAG = "aht10";
static const uint8_t AHT10_CALIBRATE_CMD[] = {0xE1};
static const uint8_t AHT10_MEASURE_CMD[] = {0xAC, 0x33, 0x00};
static const uint8_t AHT10_DEFAULT_DELAY = 75;    // ms, for calibration and temperature measurement
static const uint8_t AHT10_HUMIDITY_DELAY = 75;  // ms
static const uint8_t AHT10_ATTEMPTS = 3;         // safety margin, normally 3 attempts are enough

void AHT10Component::setup() {
  ESP_LOGCONFIG(TAG, "Setting up AHT10...");

  if (!this->write_bytes(0, AHT10_CALIBRATE_CMD, sizeof(AHT10_CALIBRATE_CMD))) {
    ESP_LOGE(TAG, "Communication with AHT10 failed!");
    this->mark_failed();
    return;
  }
  uint8_t data = 0;
  if (this->write(&data, 1) != i2c::ERROR_OK) {
    ESP_LOGD(TAG, "Communication with AHT10 failed!");
    this->mark_failed();
    return;
  }
  delay(AHT10_DEFAULT_DELAY);
  if (this->read(&data, 1) != i2c::ERROR_OK) {
    ESP_LOGD(TAG, "Communication with AHT10 failed!");
    this->mark_failed();
    return;
  }
  if (this->read(&data, 1) != i2c::ERROR_OK) {
    ESP_LOGD(TAG, "Communication with AHT10 failed!");
    this->mark_failed();
    return;
  }
  if ((data & 0x68) != 0x08) {  // Bit[6:5] = 0b00, NORMAL mode and Bit[3] = 0b1, CALIBRATED
    ESP_LOGE(TAG, "AHT10 calibration failed!");
    this->mark_failed();
    return;
  }

  ESP_LOGV(TAG, "AHT10 calibrated");
}

void AHT10Component::update() {
  if (!this->write_bytes(0, AHT10_MEASURE_CMD, sizeof(AHT10_MEASURE_CMD))) {
    ESP_LOGE(TAG, "Communication with AHT10 failed!");
    this->status_set_warning();
    return;
  }
  uint8_t data[6];
  uint8_t delay_ms = AHT10_DEFAULT_DELAY;
  if (this->humidity_sensor_ != nullptr)
    delay_ms = AHT10_HUMIDITY_DELAY;
  bool success = false;
  for (int i = 0; i < AHT10_ATTEMPTS; ++i) {
    ESP_LOGVV(TAG, "Attempt %d at %6u", i, millis());
    // delay_microseconds_accurate no longer needed as delay(delay_ms) was added in last release
    //delay_microseconds_accurate(4);
    //
    // the 'this->write(&reg, 1)' makes the aht10 unreliable again. after removing this part measurements are ok.  
    //uint8_t reg = 0;
    //if (this->write(&reg, 1) != i2c::ERROR_OK) {
    //  ESP_LOGD(TAG, "Communication with AHT10 failed, waiting...");
    //  continue;
    //}
    delay(delay_ms);
    if (this->read(data, 6) != i2c::ERROR_OK) {
      ESP_LOGD(TAG, "Communication with AHT10 failed, waiting...");
      continue;
    }

    if ((data[0] & 0x80) == 0x80) {  // Bit[7] = 0b1, device is busy
      ESP_LOGD(TAG, "AHT10 is busy, waiting...");
    } else if (data[1] == 0x0 && data[2] == 0x0 && (data[3] >> 4) == 0x0) {
      // Unrealistic humidity (0x0)
      if (this->humidity_sensor_ == nullptr) {
        ESP_LOGVV(TAG, "ATH10 Unrealistic humidity (0x0), but humidity is not required");
        break;
      } else {
        ESP_LOGD(TAG, "ATH10 Unrealistic humidity (0x0), retrying...");
        if (!this->write_bytes(0, AHT10_MEASURE_CMD, sizeof(AHT10_MEASURE_CMD))) {
          ESP_LOGE(TAG, "Communication with AHT10 failed!");
          this->status_set_warning();
          return;
        }
      }
    } else {
      // data is valid, we can break the loop
      ESP_LOGVV(TAG, "Answer at %6u", millis());
      success = true;
      break;
    }
  }
  if (!success || (data[0] & 0x80) == 0x80) {
    ESP_LOGE(TAG, "Measurements reading timed-out!");
    this->status_set_warning();
    return;
  }

  uint32_t raw_temperature = ((data[3] & 0x0F) << 16) | (data[4] << 8) | data[5];
  uint32_t raw_humidity = ((data[1] << 16) | (data[2] << 8) | data[3]) >> 4;

  float temperature = ((200.0 * (float) raw_temperature) / 1048576.0) - 50.0;
  float humidity;
  if (raw_humidity == 0) {  // unrealistic value
    humidity = NAN;
  } else {
    humidity = (float) raw_humidity * 100.0 / 1048576.0;
  }

  if (this->temperature_sensor_ != nullptr) {
    this->temperature_sensor_->publish_state(temperature);
  }
  if (this->humidity_sensor_ != nullptr) {
    if (std::isnan(humidity))
      ESP_LOGW(TAG, "Invalid humidity! Sensor reported 0%% Hum");
    this->humidity_sensor_->publish_state(humidity);
  }
  this->status_clear_warning();
}

float AHT10Component::get_setup_priority() const { return setup_priority::DATA; }

void AHT10Component::dump_config() {
  ESP_LOGCONFIG(TAG, "AHT10:");
  LOG_I2C_DEVICE(this);
  if (this->is_failed()) {
    ESP_LOGE(TAG, "Communication with AHT10 failed!");
  }
  LOG_SENSOR("  ", "Temperature", this->temperature_sensor_);
  LOG_SENSOR("  ", "Humidity", this->humidity_sensor_);
}

}  // namespace aht10
}  // namespace esphome

I don't know why this is not in the official release, but this is working for me.
I have no filters.

krunkel commented 2 years ago

For me the current version is working fine: time out on first read - but this is expected behavior... [12:15:44][D][aht10:083]: AHT10 is busy, waiting... [12:15:44][D][sensor:113]: 'temp_garage': Sending state 13.85937 °C with 2 decimals of accuracy [12:15:44][D][sensor:113]: 'vochtigheid_garage': Sending state 62.90979 % with 2 decimals of accuracy

yaml used: .. i2c: sda: 4 scl: 5 scan: True .. .. .. sensor:

greetings, Gert

Op wo 29 dec. 2021 om 12:06 schreef Padm59 @.***>:

I use this in my custom external componenet:

// Implementation based on:// - AHT10: https://github.com/Thinary/AHT10// - Official Datasheet (cn):// http://www.aosong.com/userfiles/files/media/aht10%E8%A7%84%E6%A0%BC%E4%B9%A6v1_1%EF%BC%8820191015%EF%BC%89.pdf// - Unofficial Translated Datasheet (en):// https://wiki.liutyi.info/download/attachments/30507639/Aosong_AHT10_en_draft_0c.pdf//// When configured for humidity, the log 'Components should block for at most 20-30ms in loop().' will be generated in// verbose mode. This is due to technical specs of the sensor and can not be avoided.//// According to the datasheet, the component is supposed to respond in more than 75ms. In fact, it can answer almost// immediately for temperature. But for humidity, it takes >90ms to get a valid data. From experience, we have best// results making successive requests; the current implementation makes 3 attempts with a delay of 30ms each time.

include "aht10.h"

include "esphome/core/log.h"

include "esphome/core/hal.h"

namespace esphome {namespace aht10 { static const char *const TAG = "aht10";static const uint8_t AHT10_CALIBRATE_CMD[] = {0xE1};static const uint8_t AHT10_MEASURE_CMD[] = {0xAC, 0x33, 0x00};static const uint8_t AHT10_DEFAULT_DELAY = 75; // ms, for calibration and temperature measurementstatic const uint8_t AHT10_HUMIDITY_DELAY = 75; // msstatic const uint8_t AHT10_ATTEMPTS = 3; // safety margin, normally 3 attempts are enough void AHT10Component::setup() { ESP_LOGCONFIG(TAG, "Setting up AHT10...");

if (!this->write_bytes(0, AHT10_CALIBRATE_CMD, sizeof(AHT10_CALIBRATE_CMD))) { ESP_LOGE(TAG, "Communication with AHT10 failed!"); this->mark_failed(); return; } uint8_t data = 0; if (this->write(&data, 1) != i2c::ERROR_OK) { ESP_LOGD(TAG, "Communication with AHT10 failed!"); this->mark_failed(); return; } delay(AHT10_DEFAULT_DELAY); if (this->read(&data, 1) != i2c::ERROR_OK) { ESP_LOGD(TAG, "Communication with AHT10 failed!"); this->mark_failed(); return; } if (this->read(&data, 1) != i2c::ERROR_OK) { ESP_LOGD(TAG, "Communication with AHT10 failed!"); this->mark_failed(); return; } if ((data & 0x68) != 0x08) { // Bit[6:5] = 0b00, NORMAL mode and Bit[3] = 0b1, CALIBRATED ESP_LOGE(TAG, "AHT10 calibration failed!"); this->mark_failed(); return; }

ESP_LOGV(TAG, "AHT10 calibrated"); } void AHT10Component::update() { if (!this->write_bytes(0, AHT10_MEASURE_CMD, sizeof(AHT10_MEASURE_CMD))) { ESP_LOGE(TAG, "Communication with AHT10 failed!"); this->status_set_warning(); return; } uint8_t data[6]; uint8_t delay_ms = AHT10_DEFAULT_DELAY; if (this->humiditysensor != nullptr) delay_ms = AHT10_HUMIDITY_DELAY; bool success = false; for (int i = 0; i < AHT10_ATTEMPTS; ++i) { ESP_LOGVV(TAG, "Attempt %d at %6u", i, millis()); // delay_microseconds_accurate no longer needed as delay(delay_ms) was added in last release //delay_microseconds_accurate(4); // // the 'this->write(&reg, 1)' makes the aht10 unreliable again. after removing this part measurements are ok. //uint8_t reg = 0; //if (this->write(&reg, 1) != i2c::ERROR_OK) { // ESP_LOGD(TAG, "Communication with AHT10 failed, waiting..."); // continue; //} delay(delay_ms); if (this->read(data, 6) != i2c::ERROR_OK) { ESP_LOGD(TAG, "Communication with AHT10 failed, waiting..."); continue; }

if ((data[0] & 0x80) == 0x80) {  // Bit[7] = 0b1, device is busy
  ESP_LOGD(TAG, "AHT10 is busy, waiting...");
} else if (data[1] == 0x0 && data[2] == 0x0 && (data[3] >> 4) == 0x0) {
  // Unrealistic humidity (0x0)
  if (this->humidity_sensor_ == nullptr) {
    ESP_LOGVV(TAG, "ATH10 Unrealistic humidity (0x0), but humidity is not required");
    break;
  } else {
    ESP_LOGD(TAG, "ATH10 Unrealistic humidity (0x0), retrying...");
    if (!this->write_bytes(0, AHT10_MEASURE_CMD, sizeof(AHT10_MEASURE_CMD))) {
      ESP_LOGE(TAG, "Communication with AHT10 failed!");
      this->status_set_warning();
      return;
    }
  }
} else {
  // data is valid, we can break the loop
  ESP_LOGVV(TAG, "Answer at %6u", millis());
  success = true;
  break;
}

} if (!success || (data[0] & 0x80) == 0x80) { ESP_LOGE(TAG, "Measurements reading timed-out!"); this->status_set_warning(); return; }

uint32_t raw_temperature = ((data[3] & 0x0F) << 16) | (data[4] << 8) | data[5]; uint32_t raw_humidity = ((data[1] << 16) | (data[2] << 8) | data[3]) >> 4;

float temperature = ((200.0 (float) raw_temperature) / 1048576.0) - 50.0; float humidity; if (raw_humidity == 0) { // unrealistic value humidity = NAN; } else { humidity = (float) raw_humidity 100.0 / 1048576.0; }

if (this->temperaturesensor != nullptr) { this->temperaturesensor->publish_state(temperature); } if (this->humiditysensor != nullptr) { if (std::isnan(humidity)) ESP_LOGW(TAG, "Invalid humidity! Sensor reported 0%% Hum"); this->humiditysensor->publish_state(humidity); } this->status_clear_warning(); } float AHT10Component::get_setup_priority() const { return setup_priority::DATA; } void AHT10Component::dump_config() { ESP_LOGCONFIG(TAG, "AHT10:"); LOG_I2C_DEVICE(this); if (this->is_failed()) { ESP_LOGE(TAG, "Communication with AHT10 failed!"); } LOG_SENSOR(" ", "Temperature", this->temperaturesensor); LOG_SENSOR(" ", "Humidity", this->humiditysensor); }

} // namespace aht10 } // namespace esphome

I don't know why this is not in the official release, but this is working for me. I have no filters.

— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/1635#issuecomment-1002540043, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACT7SRNAG3ME3XJCBDQKL5LUTLTUZANCNFSM4TXWHWUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

quizzical86 commented 2 years ago

Hartelijk dank Gert, I tried your suggestions (the custom external component, as well as your YAML). Doesn't help unfortunately. And I've only been able to get initial values from the sensor once, even if I've tried dozens of configurations now.

krunkel commented 2 years ago

Which version are you using? Problems with AHT10 was solved in ESPHome 2021.12.0

Greetings, Gert

Op wo 29 dec. 2021 om 15:42 schreef quizzical86 @.***>:

Hartelijk dank Gert, I tried your suggestions (the custom external component, as well as your YAML). Doesn't help unfortunately. And I've only been able to get initial values from the sensor once, even if I've tried dozens of configurations now.

— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/1635#issuecomment-1002627743, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACT7SROTQVDMNZ3SFXHHN6LUTMM53ANCNFSM4TXWHWUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

quizzical86 commented 2 years ago

I'm on 2021.12.5 so that can't be the problem, thanks anyhow for the good suggestion!

oxan commented 2 years ago

I'm on 2021.12.5

Are you sure you're using ESPHome 2021.12, as there's no ESPHome 2021.12.5 (yet).

quizzical86 commented 2 years ago

Thanks for checking and sorry for my mistake. I meant 2021.12.1, I was confusing ESPHome and Home Assistant ;-)