I have never utilized DeepSleep on an ESP32 (any any board, for that matter! 
) So, I am not really an expert on DeepSleep. However, I am guessing that you may need to enable the Internal Pullup feature during sleep for this to work, depending on how you've got everything wired up.
Take a look at In-Depth: ESP32 Deep Sleep & Wakeup Sources | Timer, Touch & External, where the use of the rtc_gpio_pullup_en() command is mentioned.
If you're going to want to have an Interrupt wake your sensor and trip an input GPIO, you are going to need a circuit similar to this:
That way you both wake up from deep sleep and trip the GPIO.
You can find a couple wiring diagrams here:
They're using a motion sensor, but you could substitute an NO contact sensor.
But also, your sketch is only ever going to run through st::Everything::run() one time. That isn't going to be enough time to check any of the interrupt sensors because they all require more than one loop to read the sensor. I would suggest only going to sleep via the callback, after the message is sent to the hub.
Got, it, Thanks, I have connected a touch sensor with 10k pull down ressistor as the sensor is having a PNP output.
I will redo this as @Ryan780 Suggested. Nevertheless Thanks again @ogiewon.
Thanks and regards,
Pugazhendhi M
@pugazhendhi.m and @Ryan780... so, you both got me a little curious... 
I was able to get the ESP32 to DeepSleep and wakeup without any special wiring whatsoever. I simply wired it like one of my normal Contact Sensor devices (i.e. GPIO pin to Ground for CLOSED, open circuit for OPEN) and added the corresponding sleep functions that I found in the article I linked earlier.
Here is a very basic example sketch that demonstrates this, using GPIO pin 33 on a NodeMCU ESP32 board. As soon as the jumper between Gnd and Pin 33 is removed, the board boots up and blinks the onboard LED, and then goes back to sleep. This is not an ST_Anything sketch, but the ESP32 Sleep Calls could be added to the end of the setup() routine in an ST_Anything sketch and it should work. Of course, the one issue is that the Contact Sensor will OPEN, but will never CLOSE. You'd either have to add some more code to toggle the state back to closed in the Arduino sketch, or tweak the Groovy Driver to auto-reset the state to closed after a few seconds.
Enjoy!
/*
ESP32_DeepSleep
*/
#include "driver/rtc_io.h"
void print_wakeup_reason(){
esp_sleep_wakeup_cause_t wakeup_reason;
wakeup_reason = esp_sleep_get_wakeup_cause();
switch(wakeup_reason)
{
case ESP_SLEEP_WAKEUP_EXT0 : Serial.println("Wakeup caused by external signal using RTC_IO"); break;
case ESP_SLEEP_WAKEUP_EXT1 : Serial.println("Wakeup caused by external signal using RTC_CNTL"); break;
case ESP_SLEEP_WAKEUP_TIMER : Serial.println("Wakeup caused by timer"); break;
case ESP_SLEEP_WAKEUP_TOUCHPAD : Serial.println("Wakeup caused by touchpad"); break;
case ESP_SLEEP_WAKEUP_ULP : Serial.println("Wakeup caused by ULP program"); break;
default : Serial.printf("Wakeup was not caused by deep sleep: %d\n",wakeup_reason); break;
}
}
// the setup function runs once when you press reset or power the board
void setup() {
Serial.begin(115200);
//Print the wakeup reason for ESP32
print_wakeup_reason();
// initialize digital pin LED_BUILTIN as an output.
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
delay(5000);
esp_sleep_enable_ext0_wakeup(GPIO_NUM_33,1);
rtc_gpio_pullup_en(GPIO_NUM_33);
esp_deep_sleep_start();
}
// the loop function runs over and over again forever
void loop() {
//should never get here due to deep sleep
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(200); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(200); // wait for a second
}
Well, I would say that is a fairly big issue, wouldn't you? That is why I said you would have to wire it up differently. So, that the board was woken up both when the contact sensor is opened and when the sensor is closed, just like zigbee and z-wave sensors are.
Also, how would you work that into a Hubduino sketch? You wouldn't simply put that into this Loop function?
esp_sleep_enable_ext0_wakeup(GPIO_NUM_33,1);
rtc_gpio_pullup_en(GPIO_NUM_33);
esp_deep_sleep_start();
The interrupt is never going to have a chance to be read if you go to sleep after one loop. Or am I not understanding how the interrupt works?
I would just make the sketch send a “closed” event after it wakes up, but before it goes to sleep. It is an assumption that the contact sensor gets reset/closed so Hubitat will be ready for the wakeup event.
This would work very well for something like a leak detector, where you only really care about being notified about a leak so you can investigate. It doesn’t work great for a true door.
I’m not sure how he wants to use it. I’m just showing how it can be used.
Has anyone experienced any issues with their boards ceasing to respond after a hub reboot? I've had a couple of instances now where after a hub reboot my Arduino board has stopped responding.
My first instance was when the electrician was in the house and cut the power for long enough for the UPS to run out of juice and crashed the HE. When I booted it back up again the motion sensors on the Arduino board wouldn't trigger. I've got relays and contact sensors on the same board as well and they were working fine. I got the motion sensors to work again by going in to each child driver and click Save Preferences.
Last thing last night I gracefully rebooted the HE. This morning I realised that none of the Arduino sensors were working (this time the relays and contact sensors weren't working either). The parent device was showing last activity recorded was from last night before the reboot and presence was indicating that it wasn't there. A click on Save preferences on the parent driver (without making any settings changes) got it going again.
Clicking save on the parent issues a ‘refresh’ command to the Microcontroller. So, that may be helping to kick-start the communications again.
What microcontrollers are you using?
Are you running the latest version of ST_Anything Arduino code? There were some changes made a while back to try and prevent issues like you’ve noted. I believe fixes were made to the ESP8266 communications code. Not sure if the other boards have the same issue.
This is for the Arduino UNO. I'm at work at the moment, so cannot check, but I think I'm on the version that was available about a month ago.
Ahhh, the UNO...with its 2KB of RAM. I definitely have not had one of those in production for a very long time. I use an Arduino MEGA and some ESP8266 boards, personally. They've been very reliable for my needs.
I've got some MEGA's on order as well but I will also continue using UNO's. Is it possible that what I'm seeing is the same thing you sorted for the ESP8266 and if so, would it be feasible to apply the same fix for the UNO?
I'm using the ST_Anything_Multiples_EthernetW5100_UNO.ino sketch and the version of the libraries is the version that was current on February 1st. I downloaded them all just after you added the support for the inactivity timer on the motion sensor.
I haven't understood the value of using any of the Arduino's over something like an ESP device. I did have a few UNOs, Minis some years ago and connected up sensors, but to get the data out you needed to add shields. Once you got to that, you were well in the territory of a Raspberry Pi with connectivity, a real CPU and lots of RAM. With the Pi Zero W, which, if you live close to a Microcenter store, goes on sale a couple of times a year for $5, making the muscle differences and price comparison rather skewed.
These days, at least for sensors, the ESP8266 boards give me a reasonable number of GPIO pins and connectivity in a small bundle. There are times when I would like to have ethernet connectivity, but I have been very happy with the ESP8266 reliability.
So I am truly curious, why would I choose a MEGA and shield? I obviously missed something, because they are still incredibly popular.
The #1 reason that I can think of is if you need a massive number of GPIO pins. Nothing comes close to what a MEGA can provide.
The #2 reason would be if you want to use a hard-wried RJ45 Ethernet connection instead of WiFi. Much easier to add a hardwired connection to an UNO/MEGA then it is on an ESP8266/ESP32 board.
It is possible, for sure. If you want to try to help test that theory, all you need to do is make a very simple edit to your copy of the SmartThingsEthernetW5100.cpp file as shown below.
At the very bottom of the file, you'll find
while (st_client.connected()) {
//while (st_client.available()) {
char c = st_client.read(); //gets byte from ethernet buffer
//if (_isDebugEnabled) { Serial.print(c); } //prints byte to serial monitor
//}
}
Try simply changing it as follows
//while (st_client.connected()) {
while (st_client.available()) {
char c = st_client.read(); //gets byte from ethernet buffer
//if (_isDebugEnabled) { Serial.print(c); } //prints byte to serial monitor
//}
}
Please report back your findings and let us know if that resolves the issue you've been seeing.
Thanks!
Cool. I'll certainly do that. Thank you 
I have some free time thanks to the "working from home" mandate. I am going to try and tackle writing a hubduino addressable LED sketch. My plan is to have two main elements: Routines and Palettes. Ideally, these would be dynamic within the hubitat driver. Additional variables such as speed, master brightness, auto cycle, duration, random, etc. could be implemented as well.
I have confidence in being able to write the C++ uC code, but very little for the groovy driver.
Is it possible for a list of available routines and palettes to be passed to the hubitat child driver?
If so, would these be available in a dropdown type menu to be able to control the device?
Would a tile work, and if so, which template?
I would hate to do all this work and not have a good way to control it.
There isn't an existing template that allows for that. As far as "routines" or "palettes", if you want to stick to standard capabilities, you can use the "Light Effects" capability. This would probably pair best with routines or patters. There really is no attribute for "palette" that would work but a custom attribute wouldn't be difficult. However, that means you would not be able to control that from a dashboard. So, I'm not quite sure what you were thinking about the control capabilities.
What library are you using as the basis for your sketch? FastLED? WS2812FX? I have a LOT of addressable LEDs in the house using a lot of different control method. I also still have a lot of extra parts so if you need anything tested, I'd be happy to try it out for you.
If you're looking for some help on the groovy side, I can defintiely try to help you there. We would just have to determine what commands you're looking to send from Hubitat for each of the different aspects you'd have to map to.
Planning to use the FastLED library. Only dashboard template I found that may work is Color Bulb. What template uses "Light Effects"? I could definitely use that for "routines" and could write an algo that matches (or creates dynamically) a palette that is closest to the RGB value sent.
I think the biggest challenge is going to be the dashboard control. (the Achilles' heel of HE)
Can you expound a bit on some of the various ways you are controlling aLEDs?
Edit:
I found this: Driver Capability List - Hubitat Documentation
and this thread that may help: LightEffects
Then how would you just get a solid RGB color? Or are you only planning on implementing effects and not solids?
solid color could be a Light Effect. If so, then match the RGB value. Else, select closest pallette.
Not sure how it should or will work yet. The key will be how to control it with the very limited dashboard options.
Download the Hubitat app
