Aircoookie
Add a usermod for AHT10, AHT15 and AHT20 temperature/humidity sensors
This pull request introduces a new usermod for integrating the AHT10, AHT15, and AHT20 humidity and temperature sensors into WLED. It uses the enjoyneering/AHT10 library to handle the wire stuff, and implements settings like:
- I2CAddress: The i2c address in decimal. Set it to either 56 (0x38, the default) or 57 (0x39).
- SensorType: Numeric 0-2 for each of the valid sensor chips
- CheckInterval: Number of seconds between readings
- Decimals: Number of decimals to put in the output
Info view.
Settings view.
VSC AFAIK detects it and uses appropriate indentation by default. You can enter anything, though.
I belive I've handled the issues. I used format document in vscode based on an editorconfig it came up with.
Quick note - the CI isn't building my usermod, right?.. If you want, I could add a sample override file directly in the usermod folder, which could be referenced by a CI job for usermods. Something like the below.
[env:sample]
extends = env:esp32dev
build_flags =
${common.build_flags} ${esp32.build_flags}
-D USERMOD_AHT10
; -D USERMOD_AHT10_DEBUG ; -- add a debug status to the info modal
lib_deps =
${esp32.lib_deps}
enjoyneering/AHT10@~1.1.0
Wire
Should I implement MQTT publishing, guarded by the "if mqtt compiled in" ifdefs?
Quick note - the CI isn't building my usermod, right?.. If you want, I could add a sample override file directly in the usermod folder, which could be referenced by a CI job for usermods. Something like the below.
Indeed. That would be nice as currently none of the usermods go through compilation process.
One more observation: Is it necessary to have "AHT Temperature" and "AHT Humidity"? There is no reason for "AHT" IMO.
Should I implement MQTT publishing, guarded by the "if mqtt compiled in" ifdefs?
That would be welcome by many users. Including HA autodiscovery broadcast.
Re. naming of info things
I was not sure what to put there. In my setup, I'll have both the BME280, AHT20 and an INA226 (tbd). As the BME280 will provide "Temperature", I wasn't sure if also providing Temperature through the AHT was going to be an issue.
As I read it, the two usermods would both be creating the u dictionary in json and adding named keys to it. If both add "Temperature" .. as I read the JSON code now, the second caller would get a reference to the same array that the first one made. So in the end, the two usermods would put in 4 values - [Temp 1, "C", Temp 2, "C"]..
Why on earth would you want two temperature sensors on one, LED driving, device?
Well. The device I got from china had both in it to provide me with 3 values (temp, humidity and pressure).. So yay me .. :D
Hilarious part is that a BMxxxx chip variant has all three values, but ... 🤷
You can always disable one of them...
Entirely true. Either code it so that temp isn't read from one of them, either a checkbox or "255" decimals meaning "don't". Or discard pressure and keep temp+humidity. :P
I'll have a look at the mqtt stuff. As for the naming of the ui json .. I can name it without AHT, but if the two usermods are run at the same time it's .. undefined..
So I:
- Added MQTT publishing
- HASS MQTT discovery publishing (stole code from BME280)
- Added settings that mimic that of BME280
- If MQTT is disabled, all of the above disappear
- I removed 5 instance bools in favor of a flags bitfield which is controlled through two macros