Channel randomly toggles with no input (Regression of past update)

[kinsi55]

Describe the bug With no input whatsoever the relay randomly toggles itself frequently. The S1 / S2 of the relay are floating, however putting the RXD1 (S1 / S2 Input) onto a different channel has the same behavior (Only leaving the button on the relay). Moving the button onto a different channel as well resolves this (At the cost of not having any input any more ofc)

~~Do I somehow need to configure a pullup / down for the button input? Changing the Button from Btn to Btn_n also resolves this, however then I need to press and hold the button for it to toggle instead of just tapping it. Additionally, this also doesnt resolve my issue of the TglChanOnTgl input.~~ See response comment

Firmware:

• Version 1.15.633 - 1.15.190
• Device: Tuya Mini Smart Switch relay clone
• Chip/model: BK7231N

[kinsi55]

Seems like this is a regression of a past update. I was able to somewhat triage it down (I didnt want to flash every specific commit).

• Issue exists in 1.15.192
• Issue does NOT exist in 1.15.183

[openshwprojects]

Can you narrow a bit more? I looked at all releases between 1.15.183 and 1.15.192 and I can't see anything suspicious.

Are you using a dInput or dInput_noPullUp?

EDIT: Are you using TglChanOnTgl ?

[kinsi55]

Yes I am using TglChanOnTgl for the external input, but on the on-relay button I'm using Btn - Both happen to do the random toggling

I also looked at the changes but couldnt find anything immediately obvious, I hoped you'd be able to make sense of it. I'll try to find the specific version at which this behaviour starts.

[kinsi55]

Okay I got the specific version, it works fine up until 1.15.188 (1.15.189 does not exist), the random toggling starts with 1.15.190

This is my I/O config (Everything else is unconfigured)

[openshwprojects]

The timer change looks suspiscious. https://github.com/openshwprojects/OpenBK7231T_App/commit/6d0938fa420f217448c4293271221db96262dd10

[openshwprojects]

Can you try latest built?

[kinsi55]

Flashed the latest build, it does still randomly toggle however now it always toggles twice in a row - So when its off it turns on and back off again, vice versa.

[andrefdavid]

I'm experiencing the same issue with the same switch, but from a Brazilian brand (Novadigital) and using the latest build. Actually, I was about to try some sort of hardware intervention, but after downgrading to build 1.15.188, the problem completely disappeared.

[openshwprojects]

I would love to fix it asap but it's hard to do it without having physical device to test.

The issue seems to have started since quick tick was changed from 5 ms to 25ms.... with last commit, I also updated debounce time to match the quick tick update by btsimonh... maybe it needs a bit more tuning to work. Can any of you do a fork of our app and try setting some different values? Online github build will provide you binaries with each commit..

[kinsi55]

Yeah I can try, which values do I need to fiddle with?

[openshwprojects]

https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/new_pins.c https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/quicktick.h

1. problems started when btSimon change quick tick from 5 to 25, so maybe revert quick tick to 5ms. This is what breaking commit does. But this will not be good for power saving.
2. Then, the better solution would be in new_pins.c: maybe debounceMS is too low for you, but it's strange, I had reports from users saying that's okay for them, so... it is almost like it's device-dependent.

Maybe after all I will make debounceMS configurable through command because it seems the desired value varies between devices... or maybe the debouncing code could be improved for ToggleChannelOnToggle.

[kinsi55]

I did some testing.

• Lowering QUICK_TMR_DURATION to 5 does not fix it
• Increasing debounceMS to 500 does not fix it

I then bridged S1 / S2 together instead of leaving them floating - This fixes it (At the cost of not having that input any more ofc).

Seems like my initial testing was wrong - The TglChanOnTgl is what triggers this. Un-assigning the external input makes this not happen. Do these MCU's have internal pullups?

[openshwprojects]

That one is with internal pull up: You can try changing HAL_PIN_Setup_Input_Pullup to HAL_PIN_Setup_Input

[kinsi55]

I removed the pullup and kinda as expected, it now constantly toggles every 500ms instead of randomly. I dont really have any other ideas. I guess for now I'll flash the old firmware and stay on that.

Also I know this is kinda unrelated but: It seems like the firmware not only crashes / reboots very often (Multiple times per hour) but also are various portions of the web interface very slow / almost unusable like the pin assignments because the page gets stuck in a half loaded state (This is not a new issue, this also happens on the old firmware)

[openshwprojects]

Do you have PowerSave 1 in startup, which is needed for devices with low quality power supplies?

[kinsi55]

I've given this issue another look now. Unlike what I had previously assumed, the issue does also exist on pre-1.15.190 - It just happens much more rarely (In 8 hours runtime it toggled on by itself twice within the first 2 hours, after that it stayed off)

New info:

• TglChanOnTgl is not the cause, it also happened once with only the builtin button assigned (Btn role)
• PowerSave 1 indeed stopped the random reboots

[paede81]

Issue still exists for me with the latest version. Anything that I can test?

[kinsi55]

@paede81 I never managed to find a solution and kinda gave up. One additional thing I noticed is that, while with 1.15.190 the issue became much more apparent, it did already exist in the version before that. I had 1.15.188 flashed on my relay and had it laying around after testing still plugged in, and it did also randomly toggle on that version after an hour or so. I'm starting to think it might just be a hardware issue.

One possible solution might be manually soldering an input to an unused pin and just using that one - No idea if that would solve it.

[konradmb]

I'm on 1.15.188 on one switch and it's reliable. Right now I see 25 days uptime and I haven't seen any toggles on it's own. Also there's like 500 ms debounce delay between trigger and reaction.

[paede81]

I'm on 1.15.188 on one switch and it's reliable. Right now I see 25 days uptime and I haven't seen any toggles on it's own. Also there's like 500 ms debounce delay between trigger and reaction.

Is the debounce delay configurable?

[konradmb]

Last time I've checked it wasn't (that was back then in 2023). It was hard-coded.