Closed jeffreykog closed 2 years ago
aht10 source aht10 issues aht10 recent changes (message by IssueLinks)
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
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. 😉
Having the same issues with AHT10, reads once then repeats same reading.
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.
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 ~_~
Same issue. Tried multiple AHT10s all with the same result; will not update sampled value
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...
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 ..
+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.
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.
@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
@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.
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. 🙃
Resolved by adding "delay_microseconds_accurate(4);" on line 63. (Pending pull request)
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"
@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.
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:
i2c:
id: bus_a
sda: 0
scl: 2
scan: True
frequency: 8khz
sensor:
- log:
[18:36:42][C][aht10:119]: Address: 0x38 [18:36:42][C][aht10:123]: Unit of Measurement: '°C' [18:36:42][C][aht10:123]: Accuracy Decimals: 1 [18:36:42][C][aht10:124]: Unit of Measurement: '%' [18:36:42][C][aht10:124]: Accuracy Decimals: 1 [18:36:42][C][homeassistant.time:010]: Home Assistant Time: [18:37:46][D][aht10:067]: AHT10 is busy, waiting... [18:39:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:39:16][D][aht10:067]: AHT10 is busy, waiting... [18:39:16][D][sensor:092]: 'AHT10 Temperature': Sending state 22.63031 °C with 1 decimals of accuracy [18:39:16][D][sensor:092]: 'AHT10 Humidity': Sending state 40.00492 % with 1 decimals of accuracy [18:40:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:40:46][D][aht10:067]: AHT10 is busy, waiting... [18:41:29][I][ota:046]: Boot seems successful, resetting boot loop counter. [18:41:47][D][sensor:092]: 'AHT10 Wifi signal': Sending state -39.00000 dB with 0 decimals of accuracy [18:42:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:42:16][D][aht10:067]: AHT10 is busy, waiting... [18:43:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:43:46][D][aht10:067]: AHT10 is busy, waiting... [18:43:46][D][sensor:092]: 'AHT10 Temperature': Sending state 22.60971 °C with 1 decimals of accuracy [18:43:46][D][sensor:092]: 'AHT10 Humidity': Sending state 40.07988 % with 1 decimals of accuracy [18:45:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:45:16][D][aht10:067]: AHT10 is busy, waiting... [18:46:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:46:46][D][aht10:067]: AHT10 is busy, waiting... [18:46:51][D][sensor:092]: 'AHT10 uptime': Sending state 632.62598 s with 0 decimals of accuracy [18:48:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:48:16][D][aht10:067]: AHT10 is busy, waiting... [18:48:16][D][sensor:092]: 'AHT10 Temperature': Sending state 22.62344 °C with 1 decimals of accuracy [18:48:16][D][sensor:092]: 'AHT10 Humidity': Sending state 40.32354 % with 1 decimals of accuracy [18:49:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:49:46][D][aht10:067]: AHT10 is busy, waiting... [18:51:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:51:16][D][aht10:067]: AHT10 is busy, waiting... [18:51:46][D][sensor:092]: 'AHT10 Wifi signal': Sending state -38.00000 dB with 0 decimals of accuracy [18:52:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:52:46][D][aht10:067]: AHT10 is busy, waiting... [18:52:46][D][sensor:092]: 'AHT10 Temperature': Sending state 22.71366 °C with 1 decimals of accuracy [18:52:46][D][sensor:092]: 'AHT10 Humidity': Sending state 40.16361 % with 1 decimals of accuracy [18:54:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:54:16][D][aht10:067]: AHT10 is busy, waiting... [18:55:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:55:46][D][aht10:067]: AHT10 is busy, waiting... [18:57:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:57:16][D][aht10:067]: AHT10 is busy, waiting... [18:57:16][D][sensor:092]: 'AHT10 Temperature': Sending state 22.84298 °C with 1 decimals of accuracy [18:57:16][D][sensor:092]: 'AHT10 Humidity': Sending state 40.02142 % with 1 decimals of accuracy [18:58:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [18:58:46][D][aht10:067]: AHT10 is busy, waiting... [19:00:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [19:00:16][D][aht10:067]: AHT10 is busy, waiting... [19:01:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [19:01:46][D][aht10:067]: AHT10 is busy, waiting... [19:01:46][D][sensor:092]: 'AHT10 Temperature': Sending state 22.85366 °C with 1 decimals of accuracy [19:01:46][D][sensor:092]: 'AHT10 Humidity': Sending state 39.91060 % with 1 decimals of accuracy [19:01:47][D][sensor:092]: 'AHT10 Wifi signal': Sending state -39.00000 dB with 0 decimals of accuracy [19:01:51][D][sensor:092]: 'AHT10 uptime': Sending state 1532.62195 s with 0 decimals of accuracy [19:03:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [19:03:16][D][aht10:067]: AHT10 is busy, waiting... [19:04:46][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [19:04:46][D][aht10:067]: AHT10 is busy, waiting... [19:06:16][D][aht10:074]: ATH10 Unrealistic humidity (0x0), retrying... [19:06:16][D][aht10:067]: AHT10 is busy, waiting... [19:06:16][D][sensor:092]: 'AHT10 Temperature': Sending state 22.86434 °C with 1 decimals of accuracy [19:06:16][D][sensor:092]: 'AHT10 Humidity': Sending state 39.74400 % with 1 decimals of accuracy
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.
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.
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.
AHT10_DEFAULT_DELAY = 8
and AHT10_HUMIDITY_DELAY = 40
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
andAHT10_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.
Hi @Padm59 I made a video about this issue https://youtu.be/4L3bv0sM8ag However, this may not work due to the recent breaking updates.
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?
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!
@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 ]
@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?
@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.
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(®, 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;
}
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.
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
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?
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(®, 1)' makes the aht10 unreliable again. after removing this part measurements are ok.
//uint8_t reg = 0;
//if (this->write(®, 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.
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(®, 1)' makes the aht10 unreliable again. after removing this part measurements are ok. //uint8_t reg = 0; //if (this->write(®, 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: @.***>
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.
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: @.***>
I'm on 2021.12.5 so that can't be the problem, thanks anyhow for the good suggestion!
I'm on 2021.12.5
Are you sure you're using ESPHome 2021.12, as there's no ESPHome 2021.12.5 (yet).
Thanks for checking and sorry for my mistake. I meant 2021.12.1, I was confusing ESPHome and Home Assistant ;-)
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 textATH10 Unrealistic humidity (0x0), retrying...
is logged, followed byAHT10 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:
Logs (if applicable):
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