AZ-Touch MOD ESP32 ADC

[wenkman-007]

First of all, awesome project, thanks for the whole thing

First of all, what I plan to do:
I found the display at AZ-Delivery and bought it as a test, with the ESP32, then I found the openHASP, which fits in my house perfectly, because I already visualize everything using Node-RED, now I wanted it in almost all rooms Assembling a display like this to control the heating/lighting/blinds.

Now my request, as you can see in the title, I would like to use an ADC pin on the ESP32 to read in values (temperature) with something like this: KY-013 and send them every 5 seconds via MQTT, but since I'm a very big noob in this regard, I need help with that.
what I have already accomplished, i can compile and upload with "Visual Studio Code", but now I don't know what to do next.

mfg

[htvekov]

Hi' @wenkman-007

I would instead go for a 1wire sensor e.g. DS18B20 or an i2c temp/humi sensor and do some custom code.
Imo much easier than dealing with an analogue thermistor an ADC pins.

I have a 1wire sample custom code lying around somewhere. Something I picked up either here in the Github discussions or in the Discord channel. I'll try and locate it, if you can't google your way to it 😉

[wenkman-007]

As I said, I'm unfortunately a total beginner

I looked into I2C, unfortunately the AZ mod uses the I2C pin to reset the display, so I rejected that.

I didn't even think about 1wire. Is 1wire possible on every pin?
because the GPIO's 25/26/32/33/34/35/36/39 would already be routed to the grid.

I've already googled a bit, but haven't found anything code-wise with 1wire

[htvekov]

No worries and welcome btw. 😎

You should be able to hook on to existing openHASP i2c bus and use this in your custom code. I've done exactly that in my proximity sensor custom code. openHASP utilizes the bus for the touch controller. Alternatively you could define your own secondary (wire1) i2c bus. You could use any (almost) free available pin/pins for i2c or 1wire connection. I don't have any insights on your devices pin config though.

I've no personal experience with 1wire devices. So far I've only used various i2c sensors.

I've located and uploaded two openHASP custom code examples other users have created and shared. You could check out these for inspiration. Uploaded to this Dropbox folder

You could also take a look at my proximity sensor custom code here

And check out the openHASP general documentation for custom code as well

[wenkman-007]

Thank you, that's exactly what helped, I bought a few sensors, I2C, analog, once they're here i will experiment.

[wenkman-007]

I have now decided on a DHT22.

the DHT is connected to 3.3V, GND and datapin to GPIO32, high with a 4.7kOhm resistor.
one value is read in every second
The values are written via MQTT every 5 seconds

here is my code for it:

#include "hasplib.h"

#if defined(HASP_USE_CUSTOM) && true // <-- set this to true in your code

#include "hasp_debug.h"
#include "custom/DHT_sensor_library_for_ESPx-1.19.0/DHTesp.h" //Download from https://www.arduino.cc/reference/en/libraries/dht-sensor-library-for-espx/
DHTesp dht;
#define DHTPIN 32

void custom_setup()
{
    // Initialization code here
    dht.setup(DHTPIN, DHTesp::DHT22);
}

void custom_loop(){
    // Not used
}

void custom_every_second(){
    // Not used
}

void custom_every_5seconds()
{
    float f_temp = dht.getTemperature();
    float f_humi = dht.getHumidity();

    char payload[60];
    char c_temp[10];
    char c_humi[10];
    String(f_temp).toCharArray(c_temp, sizeof(c_temp));
    String(f_humi).toCharArray(c_humi, sizeof(c_humi));
    snprintf_P(payload, sizeof(payload), PSTR("{\"Humi\":%s,\"Temp\":%s}"), c_humi, c_temp);
    dispatch_state_subtopic("custom",payload);
}

bool custom_pin_in_use(uint8_t pin)
{
    switch(pin) {
        case DHTPIN:
            return true;
        default:
            return false;
    }
}

void custom_get_sensors(JsonDocument& doc){
    // Not used
}

void custom_topic_payload(const char* topic, const char* payload, uint8_t source){
    // Not used
}

#endif // HASP_USE_CUSTOM

[htvekov]

I'm just curious 🙂
Do you really need to make a temperature read every second and push the mqtt message every five senconds ?
Not an issue if the read only takes a few milliseconds, but perhaps you should measure time spend in the read loop with some log entries before and after temp/humi reads

[wenkman-007]

I have now changed, but I want the values every 5 seconds

[htvekov]

Don't change it on my account 🙂
I just wanted you to consider that the time spend in your custom loop could take up a considerable amount of mcu time/percentage every second. All depending on how fast the 1wire library actually is. If it's superfast, then no worries. But if it take e.g. 100 ms to complete the read, you'll take 10% of the total available mcu ressources. That could impact the openHASP GUI responsiveness or just openHASP behaviour in general.

If you have a defined temperature delta, then you could also consider to throttle the every 5 second mqtt messages. E.g. 0.5 degree C delta check, so you'll only issue a MQTT message, when the temperature read is either 0.5 degrees higher or lower than last reported temperature.

Just a suggestion to keep mqtt chatter to a minimum and custom code time consumption as low as possible 😆

In my own proximity sensor custom code, I've throttled my sensor read (after first detection) to five seconds for the exact same reason. A complete sensor read, write to log and issuing mqtt messages takes rougly 115 ms. in total. Not an issue for the first detection, as openHASP is idle and backlight is off. But when proximity is detected, I don't want repetitive sensor reads to slow down openHASP while user is operating the openHASP device.

[fvanroie]

I don't really know, but I suppose the speed is okay.

However, I would read the temperature in the 5_seconds loop, then calculate the average of the last 5 readings + the new one and also send that out to MQTT. Then update the retained values with the new one, like you do now, but all in the 5_seconds loop...

That way, you only read new values once every 5 seconds and you still get an update also every 5 seconds.
The 6-value average over the last 30 seconds is calculated and sent over MQTT as per your requirements.

Just my 2 cents.

[wenkman-007]

I have now added this for testing

    Time_1 = millis();
    float f_temp = dht.getTemperature();
    Time_2 = millis() - Time_1;
    float f_humi = dht.getHumidity();    
    Time_3 = millis() - Time_1;

    char payload[60];
    char c_temp[10];
    char c_humi[10];

    String(f_temp).toCharArray(c_temp, sizeof(c_temp));
    String(f_humi).toCharArray(c_humi, sizeof(c_humi));
    snprintf_P(payload, sizeof(payload), PSTR("{\"Humi\":%s,\"Temp\":%s}"), c_humi, c_temp);
    dispatch_state_subtopic("custom",payload);

    String(Time_2).toCharArray(c_temp, sizeof(c_temp));
    String(Time_3).toCharArray(c_humi, sizeof(c_humi));
    snprintf_P(payload, sizeof(payload), PSTR("{\"Humi\":%s,\"Temp\":%s}"), c_humi, c_temp);
    dispatch_state_subtopic("zeit",payload);

the answer is: {"Humi":6,"Temp":6}

should actually be fast enough

[htvekov]

the answer is: {"Humi":6,"Temp":6}

should actually be fast enough

6 millis - Wow, fast library indeed! 🚀
No worries then 😎