Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output turns on by itself after several hours of being off #2348

Open
Tellicious opened this issue Jan 18, 2025 · 3 comments
Open

Output turns on by itself after several hours of being off #2348

Tellicious opened this issue Jan 18, 2025 · 3 comments

Comments

@Tellicious
Copy link

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
Copy link
Owner

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

@Tellicious
Copy link
Author

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants