Sonoff 4CH Pro Interlocking

[xoseperez]

Originally reported by: Marcus van Dam (Bitbucket: m4rcu5_net, GitHub: Unknown)

---

Hi,

When enabling the interlocking mode using the dip switches on the 4CH Pro version. The relay controls are erratic.
Sometimes, when you toggle 1 on, 2 on, 1 off, it does behave interlocking, although interface wise this looks a bit odd. But sometimes it resets the device.
This bug seems to be easier to trigger if (in interlocking mode) you enable 3 channels and then turn one off.

[RELAY] #0 set to ON
[RELAY] Saving mask: 1
[WEBSOCKET] Requested action: relay
[RELAY] #1 scheduled ON in 0 ms
[RELAY] #1 set to ON
[BUTTON] Pressed #0, event: 1
[RELAY] Saving mask: 3
[WEBSOCKET] Requested action: relay
[RELAY] #2 scheduled ON in 0 ms
[RELAY] #2 set to ON
[BUTTON] Pressed #1, event: 1
[RELAY] Saving mask: 7
[WEBSOCKET] Requested action: relay
[RELAY] #1 scheduled OFF in 0 ms
[RELAY] #1 set to OFF
[BUTTON] Pressed #1, event: 4
[WEBSOCKET] Requested action: relay
[RELAY] #0 scheduled OFF in 0 ms
[RELAY] #0 set to OFF
[BUTTON] Pressed #0, event: 4

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld
[SETTINGS] EEPROM size: 4096 bytes
[SETTINGS] Settings size: 335 bytes

I've also managed to factory reset on a relay toggle this way.

I'm using espurna-1.10.1-itead-sonoff-4ch-pro.bin
Board version v1.1 2017-5-9

[xoseperez]

Do not enable inter-locking mode. The device should be in self-locking mode, which means S1 to ON and K5 to ON (all of them). Any other configuration is not compatible with ESPurna since the STM interferes in the relays statuses. You can do inter-locking from ESPurna anyway.

[xoseperez]

Original comment by Marcus van Dam (Bitbucket: m4rcu5_net, GitHub: Unknown):

---

OK, clear. Thanks!

I was comparing code with the Tasmota project to see how they handle it, as their implementation seems to be able cope with the STM handling the relay logic quite well.

[xoseperez]

I've spent a bit of time studying the communication between the STM32 and the ESP8285 in the 4CH Pro. Apparently, the problem only rises with interlock mode (switch S6 set to 0).

With S6 switch to 0 (interlock mode) if there is a relay ON and you click on another relay button, the STM32 sends a "press" event for the button of the first relay (hold the GPIO down) but it does not send a "release" event (it doesn't release it to HIGH again). It's like it's holding the button down since you can see it is still LOW. Whatever reason the result is that it may actually perform a long click or long-long click. And by default with ESPurna the first button long click sets the board into AP mode and the long-long click triggers factory reset (OMG)!

I've changed the configuration of the board (in hardware.h) to prevent those unwanted actions. It's in the dev branch (5ed7d55) and will be released with next version.

[xoseperez]

Original comment by Marcus van Dam (Bitbucket: m4rcu5_net, GitHub: Unknown):

---

I've just build and tested the latest dev branch.

I can confirm that it will no longer hard reset the device when toggling the switches.
It also almost just works as expected; switching 1 channel on, and then the other, does interlock and switches the previous one off. This just does not /always/ work, sometimes it just visually toggles both in the interface, but on the board nothing happens. until you manually switch the old channel off, then it toggles.

I am not sure why this is.

[xoseperez]

Do you mean you see the toggle switching in the web UI but the actual relay doesn't change? Can you get a log while that happens and copy it here?

[xoseperez]

I've been testing it and it looks like a feature/bug in the STM microcontroller. Sometimes one of the buttons just stops working but ESPurna and ESPurna does not receive any output from it...

[xoseperez]

Will be released with 1.12.2