Am trying the touch input in the ESP32. I did an interrupt attach and was getting a reset. Changed to touchRead invoked by timer (1sec) and processing if read value is below 20.
Just did a serial monitor output of the value read. When there is no touch, out of 15 readings or so, one reading comes low, triggering the touch input. Seems flaky as a sensor to me.
Does anybody have any suggestions on how we could make it robust?
Add a capacitor to it I guess. That would be my solution.
Not a Blynk specific thing 
… Lots of example out there, and the touch sensors seem fairly robust. Just need as little hardware as a wire.
As they are capacitive sensors the readings will have a bit of variance… internal averaging and hysteresis is probably required for stability.
I’m right now using the board and touching the pad of the pin provided to solder them. Are you saying actually soldering a pin and attaching a wire would resolve the widely fluctuating reading issue? Normal value being read is 128. One reading comes up around 10 in between 20 read instances showing 128.
I’m thinking of having a counter and recognise a touch only if the reading is low for 3 consecutive 500ms spaced readings. This will also negate accidental touches triggering an action.
The touch interrupt example works well. However, in my sketch, touch interrupt invoked on touch causes a reset. I removed the blink.virtualWrite() in the routine invoked by the interrupt and no resets took place. I’m cumventing the problem using touchRead which does not seem to have this problem even when blynk.virtualWrite() is embedded.
Is interrupt more efficient than a user timer driven event? If so, I would try to get this to work. If not, I’m good with my timer thingy.
Logic tells me that the interrupt will probably be polled more often but possibly by the core dedicated to FreeRTOS.
Gurus - any responses?
Confirmed that blynk.virtualWrite called in a routine triggered by touchAttachInterrupt causes a " Guru: meditation error" a screen dump and a reset.
Used a counter to detect continuous touch over 5 x 200ms timer invoked calls to get rid of spurious low values that do not last more than 2 consecutive cycles. Figured that this would also solve the button bounciness or unintended touch problem common in touch.
Can someone figure out why interrupt attach using blynk.virtualWrite fails? Serial.primt etc all gf o through fine and sondies the example without any blynk calls.
Thanks to @Gunner and others who write on not having too many simultaneous timer invoked calls. I used a delay of 100ms initially and then slices of 200ms thus always having a minimum of 100ms offset from the second tick. Two other timer calls are.trigerred on second tick.