Output turns on by itself after several hours of being off

[Tellicious]

System description
The accessory has:

• 3 physical inputs:
  • PIN0 BUTTON1
  • PIN21 BUTTON2
  • PIN12 TRIGGER
• 7 outputs configured, of which 3 are used right now:
  • PIN15 LED
  • PIN34 OUT1
  • PIN33 OUT2
• 4 services:
  • 1 Lock, exposed as a switch to Homekit and controlled by BUTTON1 and BUTTON2
  • 2 Command, exposed as a plug to Homekit
  • 3 Trigger Status, hidden
  • 4 Control, hidden

The system is meant to turn on Command when Lock OR Trigger Status are on and to turn it off when Lock AND Trigger Status are off. Lock is also re-set every night at 2 am. The two Command outputs, OUT1 and OUT2 are meant to be turned on and off with a delay of 42s when turning on and 2s, in reverse order, when turning off.

I know the same result could be achieved through a Free Monitor that sums Lock and Trigger Status and that commands Command, however I wanted to make it in a bit more interesting way

Issue
It generally works exactly as intended however, randomly, and usually after several hours/days that the system is off, OUT2 turns on by itself, with Lock and Control off in Homekit and with OUT1 off. What could be the reason?

MEPLHAA Script

{"c":{"io":[[[1,2,3,4,5,6,7,8,9,10,11,13,14,16,17,18],0],[[15,34,33,36,35,38,37],2],[[0,21],6,1],[[12],6]],"l":15,"i":0,"b":[[0,5],[21,5]],"o":8,"10":{"m":[[1,0]]},"tt":[[10,2,0]],"n":"HAA-StereoCtrl","ntp":"ntp1.inrim.it","tz":"CET-1CEST-2,M3.5.0/2,M10.5.0/3"},
    "a":[
        {
        "0":{"m":[[4,-10001],[2,-20001]]},
        "1":{"m":[[2,-20000],[2,1]]},
        "b":[[0],[21]]
        },
        {
        "t":2,
        "xa":0,
        "0":{"r":[[33],[34,1,2]]},
        "1":{"r":[[34,1],[33,0,42]]},
        "f0":[[12]],
        "f1":[[12,0]]
        },
        {
        "h":0,
        "g0":[[12]],
        "g1":[[12,0]],
        "s":4
        },
        {
        "t":80,
        "h":0,
        "n":5,
        "xa":0,
        "ks":2,
        "j":2,
        "dt":[0,2,0,2,3,0],
        "y0":[
            {"v":-1,"r":1,"0":{"m":[[2,1],[0,-10000]]}},
            {"v":0,"r":1,"0":{"m":[[0,-10000]]}},
            {"v":1,"r":1,"0":{"m":[[2,0],[0,-10000]]}}
            ]
        }
]}

Used device
ESP32-S2
HAA version
12.14.5

[RavenSystem]

It seems that something is causing a reboot. Logs are needed to debug it.

[Tellicious]

Alright, will setup a log server and wait for a failure.

By the way, during a normal boot both exits are initialized as 0. Just out of curiosity, why should it differ with a reboot?

[Tellicious]

Ok, now I have the logs. It seems that the weird behavior is due to TRIGGER being toggled ON and OFF within 2 seconds, before the 42 seconds ON delay of pin 33 are over.

Jan 26 03:20:14 192.168.4.82-C53812 [52] Get CH
Jan 26 03:21:05 192.168.4.82-C53812 NTP ntp1.inrim.it (0)
Jan 26 03:21:14 192.168.4.82-C53812 [52] Get CH
Jan 26 03:21:41 192.168.4.82-C53812 <3> DigI S1 GPIO 12
Jan 26 03:21:41 192.168.4.82-C53812 <3> SW St ON 1
Jan 26 03:21:41 192.168.4.82-C53812 <2> DigI 1 GPIO 12
Jan 26 03:21:41 192.168.4.82-C53812 <2> SW ON 1
Jan 26 03:21:41 192.168.4.82-C53812 Setup 1/8
Jan 26 03:21:41 192.168.4.82-C53812 <2> Run A1
Jan 26 03:21:41 192.168.4.82-C53812 <2> DigO 34->1 (0)
Jan 26 03:21:41 192.168.4.82-C53812 <2> DigO 33->0 (42000)
Jan 26 03:21:43 192.168.4.82-C53812 <3> DigI S0 GPIO 12
Jan 26 03:21:43 192.168.4.82-C53812 <3> SW St ON 0
Jan 26 03:21:43 192.168.4.82-C53812 <2> DigI 0 GPIO 12
Jan 26 03:21:43 192.168.4.82-C53812 <2> SW ON 0
Jan 26 03:21:43 192.168.4.82-C53812 Setup 1/8
Jan 26 03:21:43 192.168.4.82-C53812 <2> Run A0
Jan 26 03:21:43 192.168.4.82-C53812 <2> DigO 33->0 (0)
Jan 26 03:21:43 192.168.4.82-C53812 <2> DigO 34->1 (2000)
Jan 26 03:21:45 192.168.4.82-C53812 Auto DigO 34->0
Jan 26 03:22:14 192.168.4.82-C53812 [52] Get CH
Jan 26 03:22:23 192.168.4.82-C53812 Auto DigO 33->1
Jan 26 03:23:14 192.168.4.82-C53812 [52] Get CH

After that event, even when service 1 is used, the OFF state of service 2 becomes PIN34 OFF and PIN33 ON

Jan 26 10:37:36 192.168.4.82-C53812 <1> DigI 2 GPIO 21
Jan 26 10:37:36 192.168.4.82-C53812 <1> SW ON 0
Jan 26 10:37:36 192.168.4.82-C53812 Setup 1/8
Jan 26 10:37:36 192.168.4.82-C53812 <1> Run A0
Jan 26 10:37:36 192.168.4.82-C53812 <1> ServNot 4->-10001
Jan 26 10:37:36 192.168.4.82-C53812 <1> ServNot 2->-20001
Jan 26 10:37:37 192.168.4.82-C53812 <4> FM: 1
Jan 26 10:37:37 192.168.4.82-C53812 <4> Wild 0->1.00
Jan 26 10:37:37 192.168.4.82-C53812 <4> Run A53
Jan 26 10:37:37 192.168.4.82-C53812 <4> ServNot 2->0
Jan 26 10:37:37 192.168.4.82-C53812 <2> SW ON 0
Jan 26 10:37:37 192.168.4.82-C53812 Setup 1/8
Jan 26 10:37:37 192.168.4.82-C53812 <2> Run A0
Jan 26 10:37:37 192.168.4.82-C53812 <2> DigO 33->0 (0)
Jan 26 10:37:37 192.168.4.82-C53812 <2> DigO 34->1 (2000)
Jan 26 10:37:37 192.168.4.82-C53812 <4> ServNot 4->-10000
Jan 26 10:37:39 192.168.4.82-C53812 Auto DigO 34->0
Jan 26 10:38:10 192.168.4.82-C53812 Auto DigO 33->1
Jan 26 10:38:36 192.168.4.82-C53812 [52] Get CH

Hope this helps to debug the issue

[RavenSystem]

In this part: "1":{"r":[[34,1],[33,0,42]]},, when action 1 is launched, GPIO 33 is set to LOW, and a timer of 42 seconds is armed and started to set GPIO 33 to HIGH. This timer can not be disabled and it will continue and it will set GPIO 33 to HIGH after depleted time. I suggest the use of an additional switch service to control GPIO 33, and manage it with service notification actions. The "i": key if the switch service is a timer that is disabled when service state go off.