Checking variable state in a function loop

[injector22]

I have a GPIO that keeps bouncing on/off which I'm thinking is due to inference but before I go ripping out cabling I wanted to try and fix it via software. Before I get started let me just say I know about debouncing on a GPIO, I have tried it but due to the length of the bouncing it renders the usability null.

What I was thinking was connect the GPIO output to a function node that just sets the output as a flow variable.
Then have another function node that loops forever, inside said loop detect when the flow variable changes value. This triggers a child loop to check the state of the flow variable for X seconds, if the state has stayed the same value for all the X seconds then send an async msg allowing the change. if however, it bounced then it's a false positive and no async is sent.

Essentially what I want to do is check the value hasn't changed in a set time vs debouncing which uses the first value, ignores for x seconds and compares again.

[Colin]

You can use a Trigger node for that. Configure it like this

That will wait until 250ms (or whatever you set) has elapsed with no change in state and then send the latest state. If you follow it with an RBE node that will stop it sending the same state twice in a row.

[injector22]

Interesting, I didn't think that would do what I described but funny enough it is working. Thank you.

[Colin]

Do you understand how it works? Always make sure you understand how something works when you import a flow as that way you will learn more.

[injector22]

Yes, the only part where I see a failure could occur is if the incorrect value isn't corrected within the x seconds since the logic isn't comparing the arrived values and instead it's doing adding a delay. Or I'm I wrong?

[Colin]

@injector22

the only part where I see a failure could occur is if the incorrect value isn't corrected within the x seconds

I am not sure what you mean by that. If the 'incorrect' value isn't corrected within the x seconds then that means it wasn't an incorrect value but a correct one. Perhaps I misunderstand what you mean.

[injector22]

Ok let me see If I'm understanding the flow correctly. When a message arrives to the trigger it will hold it for X seconds, if another message arrives it will then wait another X seconds. If no new message arrives the last received message is then released.

So if the correct value from the hardware attached to the GPIO is 0, the pin is currently at 0, the trigger receives 0 (the timeout is set for 5 seconds). Within 4 seconds interference kicks in and the trigger receives a 1 but the 1 stays as the last message for 5 seconds because the interference did not clear up until 6 seconds in.

Wouldn't the trigger node then release the 1 it held for 5 seconds?

[Colin]

If it stays at 1 for 5 seconds what logic can you use to say whether it is a real signal or interference? I can't see any way of distinguishing.
If the interference is induced pickup (which is the normal situation) then it won't stay in one state for a long time it will bounce up and down rapidly so the trigger will keep getting restarted. If you are getting a false signal which holds it in the wrong state for several seconds (or even significant fractions of a second) then it is not induced interference, you must have a DC signal connected in there somehow. Possibly an earth loop or something like that. Even then though that would normally be AC. So possibly you have a DC signal flowing down the 0V connection.

[Edit] What is the input wired up to?