Is there a rule trigger like "ON Rule1#State==1 DO ..... ENDON" ?

[coolman111]

Hi, I'm playing around a little bit with Rule coding in order to optimize the features of a Gosund SP111 WiFi plug.
e.g. to use the plug in normal On/Off mode and, as an enhancement, to use it as a countdown timer which switches the relay off when the timer ended after xx seconds.
Making a 4x click on the physical button of the plug, I change the state from On/Off mode to timer mode, and 4x clicking again, back to On/Off mode.
My rules are working perfectly, but a want to change dynamically the Button Label in the WebGUI in order to show the current state of the mode (On/off or Timer).
My problem is the following: (I show only a part of the code for not to make it complicate)
Rule1
On .... ENDON // Comment: Setting timer, var, etc
...
Rule2
ON Button1#State==13 DO Rule1 Toggle ENDON //Comment: this toogles my Rule1 to On or Off when 4x click

//Comment: Rule1 ON -> Time Mode, Rule1 OFF -> normal On/Off mode.
Until here everthing works perfectly.
Now what does not work:
Rule3
ON Rule1#State==1 DO WebButton1 Timer Mode ENDON
ON Rule1#State==0 DO WebButton1 On/Off Mode ENDON
//Comment: Rule3 should set the label of the Button1 in condition of Rule1 is On or Off.
This does not work at all. The excecution of Rule3 is not be shown in the Webconsole log.
Remark: I know, the Button label will not be updated with WebSocket, you have to reload the web page to see changes.
That is not the problem.
When I use a another trigger, the label changes. eg. Power1#State==1 ...
The problem is that the trigger "Rule1#State==1" does not work.
IMHO, there should be a trigger for this, because the answer to the command:
Rule1
RESULT = {"Rule1":"OFF","Once":".........................}
is a JSON payload.
I tried also variants like:
Rule1#State=OFF, Rule1#Data==1, Rule1#Data=OFF etc. Nothing helps.

Does anyone has a clue of what is happening here?
Is the Trigger Rule#State==1 valid?
Hope, we can find a solution.

[ascillato]

The available rule triggers are only the ones explained in the docs at rules (https://tasmota.github.io/docs/Rules/).

The trigger Rule#State==1 is NOT VALID and is not going to be added because Enabling and disabling rules as you are doing will wear your flash. Sorry.

It is better to use a VAR for your use case instead.

[sfromis]

While using the enabled/disabled status of rules is indeed not really recommended, this JSON based trigger works:
on Rule1 do var1 %value% endon

[coolman111]

@ascillato: Yes, that's what I already suspected, Rule1#State is not valid. But the hint from sfromis "on Rule1 do var1 %value% endon" does work indeed. On this way I can get the status of Rule1 (active or inactive).
By the way, I already knew that writing to items stored in flash will wear the flash if you do it very often.
But when this happens in my rules, I guess, once per day or week or less, maybe this would not be a problem for the flash ?
Anyway I want to keep the status of the working mode of the plug, even after reboot or power loss. So IMHO would there be a big difference of writing a number into Mem(x) or toggling the active state of a rule, which should be toggling a bit or byte, but not rewriting the whole rule ? I can't use a var for this, because vars are in RAM and removed while booting.
I would like to outline briefly how my configuration works:

Item: a Gosund SP111 V1.1 WiFi plug with Tasmota 9.2.0 precompiled binary, red LED=Power On, blue LED=WiFi
Purpose: To switch off automatically dangerous devices like a laundry iron, without using external scripts or MQTT.
Function:
You can use the plug in 3 ways (on/off, timer 1, timer 2):
A) Standard mode of Tasmota software: relay On / Off mode (my Rule 1 is inactive)
1x Button On / Off / On / Off etc. (toggling)
B) Countdown Timer Mode
1x Button On -> Start timer running for e.g. 15 minutes, 30 sec. before end, red LED flashes, then power off
1x Button during timer run -> Time is reset to full time again (you can iron longer)
Hold Button during run (3 sec) -> stop timer and power off.
2x Button click -> set timer to time1(e.g. 15 min.)
3x Button click -> set timer to time2(e.g. 30 min.) -> during boot will be reset to time1
4x Button click -> toggle Mode A) to B) and vice versa -> Rule1=Off Mode A), Rule1=On Mode B) -> Mode kept during boot (important)!
5x Button click -> Reboot device (I had to implement this, because when it is in Timer Mode (B) and you click accidently 6x, you enter WiFiManager Mode for 3 Minutes, and you CANNOT come out from here by 1 click (like in default Tasmota Mode (A) !
Without rebooting, you must wait 3 minute in this case.
=> for security reason, the relay will be powered off after a reboot and after loss of mains (230V) !
=> for control purpose, the relay button label in the WebGUI will be changed accordingly to: On / Off or Timer 15 min. or Timer 30 min.
=> the Button clicks 2x, 3x, 4x and 5x are working in both modes A) B)
All this is done in 3 rules and now working perfectly.
As I mentioned before, the flash memory will be weared only when you change Mode A) or B). This would be very, very rarely done.
The times for the timer are stored in flash only once.

Thanks for your help.
If you are interested, I'll be happy to post the complete code.
Cheers ;-)

[sfromis]

Writing flash settings is all 4K when it happens, it does not make much difference counting changed bits. As long as you do not trigger flash writes many times a day, the expected weardown time (assuming that the nominal value of 100000 writes hold) should be decades. Tasmota rotates among 8 slots, but I'm not sure if this translates to 8 times the lifetime.

[meingraham]

This falls into the "every Tasmota command result is a rule trigger" category. Rule1#Data would be the "documented" trigger.

[sfromis]

Actually not. Rule1#Data would only work if the JSON output only has one field. But Rule1 without any qualifier works for top level JSON fields, as long as there is not only one, as in
{"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Length":30,"Free":481,"Rules":"on Rule1 do var1 %value% endon"}
Single-field JSON triggers is a special case, deviating from the general where # is only used to go inside JSON objects, by requiring the use of Name#Data