Sonoff T1 Touch Lockup

[Fusseldieb]

Bug description
If I press the touch buttons multiple times in a row, it will lock up after 3-4 times and only respond after 1-2 seconds again. This happens with the touch buttons, in the Web UI and inside HassIO (when configured over MQTT).

Steps to reproduce
Flash it, let it boot up and then press the touch buttons repeatedly until it locks up for 1-2 seconds, normally this happens after 3-4 presses.

Expected behavior
That no matter how many times I press it, it doesn't lock up after 3-4 times.

Device information

• ESPurna version 1.13.4
• Flash mode Serial FTDI (GPIO0+GND -> Erase flash -> GPIO0+GND -> Espurna T1 bin)
• Device brand, model and version SONOFF T1 1.0 US (ESP8285)

[mcspr]

You sure it locks up and not resetting? If so, i think it is intended behaviour:

espurna/code/espurna/config/general.h

Lines 339 to 347 in 5c0abca

	// Relay requests flood protection window - in seconds
	#ifndef RELAY_FLOOD_WINDOW
	#define RELAY_FLOOD_WINDOW 3
	#endif
	// Allowed actual relay changes inside requests flood protection window
	#ifndef RELAY_FLOOD_CHANGES
	#define RELAY_FLOOD_CHANGES 5
	#endif

i.e. it will allow 5 changes in 3 second window. You can check the telnet / serial log for lines like this:

[427429] [RELAY] #1 scheduled ON in 657 ms

And you might want to update to 1.13.5 if the device resets

[Fusseldieb]

Thanks for the fast reply

You sure it locks up and not resetting? If so, i think it is intended behaviour:

Yes, it's locking up, not resetting, since the WiFi doesn't vanish and the WebUI reponds immediately after 1-2 seconds again.

i.e. it will allow 5 changes in 3 second window.

I didn't knew that ESPURNA had a flood protection... That could be it.

A option to disable it via the WebUI would be nice.

EDIT:

Yes, it's the flood protection:

[731953] [WEBSOCKET] #1 connected, ip: 192.168.2.106, url: /ws
[734532] [WEBSOCKET] Requested action: relay
[734534] [RELAY] #1 scheduled ON in 0 ms
[734537] [RELAY] #1 set to ON
[734539] [MQTT] Sending COZINHA-T1/relay/1 => 1 (PID 1)
[734738] [WEBSOCKET] Requested action: relay
[734740] [RELAY] #0 scheduled ON in 0 ms
[734742] [RELAY] #0 set to ON
[734745] [MQTT] Sending COZINHA-T1/relay/0 => 1 (PID 1)
[735109] [WEBSOCKET] Requested action: relay
[735111] [RELAY] #0 scheduled OFF in 0 ms
[735114] [RELAY] #0 set to OFF
[735116] [MQTT] Sending COZINHA-T1/relay/0 => 0 (PID 1)
[735327] [WEBSOCKET] Requested action: relay
[735330] [RELAY] #1 scheduled OFF in 0 ms
[735332] [RELAY] #1 set to OFF
[735335] [MQTT] Sending COZINHA-T1/relay/1 => 0 (PID 1)
[736337] [RELAY] Setting relay mask: 0
[738485] [WEBSOCKET] Requested action: relay
[738488] [RELAY] #0 scheduled ON in 0 ms
[738490] [RELAY] #0 set to ON
[738492] [MQTT] Sending COZINHA-T1/relay/0 => 1 (PID 1)
[738810] [WEBSOCKET] Requested action: relay
[738812] [RELAY] #0 scheduled OFF in 0 ms
[738815] [RELAY] #0 set to OFF
[738817] [MQTT] Sending COZINHA-T1/relay/0 => 0 (PID 1)
[738939] [WEBSOCKET] Requested action: relay
[738941] [RELAY] #0 scheduled ON in 0 ms
[738944] [RELAY] #0 set to ON
[738946] [MQTT] Sending COZINHA-T1/relay/0 => 1 (PID 1)
[739098] [WEBSOCKET] Requested action: relay
[739101] [RELAY] #0 scheduled OFF in 0 ms
[739103] [RELAY] #0 set to OFF
[739105] [MQTT] Sending COZINHA-T1/relay/0 => 0 (PID 1)
[739242] [WEBSOCKET] Requested action: relay
[739245] [RELAY] #0 scheduled ON in 2243 ms
[739398] [WEBSOCKET] Requested action: relay
[739401] [RELAY] #0 scheduled change cancelled
[739566] [WEBSOCKET] Requested action: relay
[739568] [RELAY] #0 scheduled ON in 1919 ms
[739718] [WEBSOCKET] Requested action: relay
[739720] [RELAY] #0 scheduled change cancelled
[739886] [WEBSOCKET] Requested action: relay
[739889] [RELAY] #0 scheduled ON in 1598 ms
[740016] [WEBSOCKET] Requested action: relay
[740019] [RELAY] #0 scheduled change cancelled
[740107] [RELAY] Setting relay mask: 0

[mcspr]

Sure, web will support it. I would not put a definitive timeline on this, but soon (tm)

And may I ask - what is the use case?

[Fusseldieb]

Sure, web will support it. I would not put a definitive timeline on this, but soon (tm)

That's nice

And may I ask - what is the use case?

It just feels unresponsive somehow, I can't really explain it better.

[xoseperez]

Flood protection was initially implemented to protect mechanical relays. But since the code is in the core of the relay.ino module it actually affects all type of switches, including light bulbs or mosfets. Having an option to disable it or, even better, define a default value per-device will be great.