Improve responsiveness of buttonpress responses

[johndoe39274]

Hey,

My home automation runs fully on ESPeasy. It has lots of 6-way wallswitches (pushbuttons) which are connected through MCP23017 I²C port expanders to ESP32 boards. The ESP's run local rules to read buttonpresses and switch a teleruptor like this:

Code: Select all

on mcp#1 do
 If [plugin#mcp#pinstate#1]=0        //button pressed
  MCPLongPulse_mS,13,0,20  // switch teleruptor
 endif
endon

I notice that the buttons are not super responsive. We need to press a button really hard to make sure the keypress is long enough to positively register. On a hardware level I am sure that the physical buttons and the MCP boards work fine. I think the delay (and sometimes missed keypresses) are caused by CPU load on the ESP, causing late reactions or even keypresses being missed because the CPU was busy with something else and polled the I²C MCP23017's too late. Each ESP has 3 MCP boards connected, so a total of 18 input pins are being monitored.

So far I have take the following steps to reduce the load on the ESP's:
- disabled hardware serial
- set Serial Log Level to none
- set Web Log Level to Info
- ensure I²C runs at 400kHz
- init SPI is disabled

Other things that use CPU that I would rather not disable:
- OpenHAB MQTT controller
- NTP

The timing stats show that Loop has a duty cycle of 91% and an average cycle time of 7.502 ms. Load = 69.39% (LC=166)

Are there any further steps I can take to reduce the load on the ESP's? Or anything I can try to troubleshoot this and make buttonpresses more responsive?

Thanks in advance!
John

[ThomasB]

I'm not using the MCP23017 so I don't have first hand experience. But I looked at the plugin and it operates at 10Hz. So 18 input pins would indeed stretch out push button detection.

Also keep in mind that the rules themselves can slow things down. Some things to try:
Strip out comments.
Simplify rules (use Mr. Karnaugh for inspiration).
Eliminate all rules that are not essential.
Move the switches that are used the most towards the top of the rule file.

On the hardware level, a simple workaround may be possible (no promises though). For example, a primitive solution might be achieved by putting a 47uF cap across each MCP23017 input so that it can act as a sample-and-hold.

Assuming you are using active low detection, and a high value pullup resistor value, when the button is pressed the cap would hold the logic level low for a couple hundred mS. Might help, or maybe not. Add a 100 ohm resistor in series with each cap to ensure safe pushswitch discharge currents.

- Thomas

[johndoe39274]

Hi Thomas,

Thanks for the reply!

Would it be trivial to update the code for the MCP23017 plugin to run at say 50 Hz?

I might try your sample-and-hold RC filter trick. My MCP boards have an RC filter on the MCP's inputs. It is aimed at filtering high frequency noise though, and consist of a 100pF parallel cap and a 1k series resistor. On the input pins I use 4k7 pull-up and do active low detection. I have some 22µF tantals that fit the 100pF footprint, I might test soldering them on top of the 100pF to see if that make a difference with the reliability of detecting keypresses.

[ThomasB]

Would it be trivial to update the code for the MCP23017 plugin to run at say 50 Hz?

If you can compile the code then you could try that out. But a dev like TD-er or ATH may offer some precautions/comments about using 50Hz updates. Maybe they will stop by and provide advice.

On the input pins I use 4k7 pull-up and do active low detection.

For my idea to work the pullup needs to be a much higher value. As a test, remove the 4K7pullup on one Pin and enable its internal pullup, which is a high ohms value. Test this with the 22uF cap to see if it helps your situation. That will confirm the idea has merit.

- Thomas

[Ath]

I don't expect that the frequency of reading the MCP really makes a difference, I expect the time needed to process the rules is the problem here, so a few tips:
- Remove anything from rules that is not needed, including comments and commented out code
- Place most often used code at the top of the rules 1 file
- Try to re-use code as much as possible (slimming down the size of the code)