Button event is issued when you save settings with status reset to 0

[andreruiz]

Hello all,

I'm trying to configure Rules to achieve what I'll describe below, and while doing that I found a strange behavior that I want to confirm. I'm using a sonoff basic r2, with mega-20231225 and my goals are:

• I want to be able to toggle a relay when I press the button.

• I want to be able to toggle that same relay over the web api calls (which I'm doing and works fine, using cmd=gpio,12,x).

• I want the button to keep toggling the relay even if the state was previously changed via web.

• The button is a Push Button Active Low and it's state changes between 0 and 1 at each press, as expected.

This seems to do the job, because it it keeps toggling the relay no matter the old state. I tried mixing button presses with API calls and it seems to work well.

Code: Select all

on Button#state do
  GPIOToggle,12
endon

Now for the problem:

If I go to the configuration interface, go to the Devices tab, and EDIT my button, and then click Submit (it does not matter if I change anything), as soon as I submit it, the relay changes state. I didn't expect that.

Looking the logs, it seems like every time I save configs, the Button instance (Task) is completely re-initialized, its state goes immediately back to 0 (no matter what it was before) and a new EVENT of Button#state=0 is emitted, causing that code to trigger and toggle the relay. You can see it below:

Code: Select all

1339335: EVENT: TaskExit#Button=1,0
1339392: EVENT: TaskInit#Button=1,1
1339400: EVENT: Button#State=0
1339408: ACT : GPIOToggle,12
1339411: GPIO toggle: port#12: set to 1
1340157: EVENT: Clock#Time=Tue,19:05

All of this log appeared as soon as I clicked Submit, without touching the button or sending any API calls. And that "EVENT: Button#State=0" did trigger the rule and the relay toggled. This is very dangerous, it is very easy for someone to try to save settings while the relay is in use. Is this intentional? What am I missing?

I tried all sorts of black magic using variables to save old state and try to check if it was a real state change but in the end nothing I did could cover all the cases. I appreciate any hints.

Thanks
Andre

[andreruiz]

Another thing that I just realized is that with that code I was having a relay toggle (to on) at boot time, probably because an event is also being emitted at TaskInit and triggering that rule. I got rid of that using a timer that will prevent acting on any events for button for a few seconds after boot, and the problem was gone. But now I'm wondering if it is the same problem and also there is a better way of avoiding it.

[andreruiz]

Ok, after I explained the issue I think I found a solution.

This code works and solves both problems at the same time (confirming that the boot issue was the same issue as saving the configuration in the web). It avoids the initial event right after the button task is (re-)initialized, at any moment in time.

Code: Select all

on TaskInit#Button do
  Let,0,0
  TimerSet,1,3 // 3 seconds
endon

on Rules#Timer=1 do
  TimerSet,1,0 // not sure if this is needed since timer expired already
  Let,0,1
endon

on Button#state do
  if [var#0]!=0
    GPIOToggle,12
  endif
endon

But the question remains, is this an expected behavior and is there some more obvious way of avoiding it?

[Ath]

The Plugin_exit and Plugin_init are indeed the default events and intended behavior, including destroying and restarting the plugin, when saving the settings. Trying to update settings on a running plugin would be way too complex and restarting the plugin should provide a defined starting-point, except... when using GPIOToggle for changing the state of the GPIO

The Switch plugin currently does generate an event on init, and that's an issue still under investigation.
The Switch plugin is also a candidate for a code-rewrite, as it has become quite complex (to use an understatement), with too many features and responsibilities, and it is often also used for 'monitoring' a GPIO pin, like a relay, though that's not the intended use and can be a cause for unexpected behavior.

You seem to have devised a decent work-around.

[andreruiz]

I see. I'll keep using this for the moment then, and I'll keep an eye on this for future changes.

Thank you!