-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AHT10 works very unreliable #1635
AHT10 works very unreliable #1635
Comments
aht10 source |
Unrelated to the code, but related to your AHT10 hardware: 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: |
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)
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:
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:
|
@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. Now I'm testing
i2c:
id: bus_a
sda: 0
scl: 2
scan: True
frequency: 8khz
sensor:
- platform: aht10
i2c_id: bus_a
address: 0x38
update_interval: 90s
temperature:
name: "AHT10 Temperature"
accuracy_decimals: 1
filters:
- filter_out: -50
humidity:
name: "AHT10 Humidity"
accuracy_decimals: 1
filters:
- filter_out: 0
Does PS: my only long-term working config was by chance with |
Just to flag that my log is also full of these messages about unrealistic values and the sensor being busy:
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.
|
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 |
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? 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 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:
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. 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?
|
@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() {
|
Thank you all for your help, works near perfectly now. 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 |
I can't get the AHT10 to work.
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. |
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:
- platform: aht10
temperature:
name: "temp_garage"
id: "temp_garage"
humidity:
name: "vochtigheid_garage"
id: "vochtigheid_garage"
update_interval: 30s
..
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->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.
—
Reply to this email directly, view it on GitHub
<#1635 (comment)>,
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, |
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
<#1635 (comment)>,
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! |
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 text
ATH10 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
The text was updated successfully, but these errors were encountered: