connected a button to RP4 and now the script running at random times

[alix2341]

I have a button connected to the RP4 board and using this kind of switch https://www.giovenzana.com/component/pcw01/ and a button, everything works fine except the fact that the script sometimes run at random times as if the button is clicked even though its not (I checked that by adding a flag when the button is clicked in the python script) I'm using the GPIO 17 and a ground pin on the board only those two, and the python script works fine its just the random clicking is there something i muissed in this case

[pcmanbob]

Hi.

You have not given us much to go on , but as you have said nothing about a pull -up resistor either a physical one or a pull - up in software that would be my first question.

Do you have a pull - up on the gpio pin you are using for input so that operation the switch pulls it down to ground ?

for ref.. https://github.com/raspberrypilearning/ ... up_down.md

[ame]

How long are the wires to your switch? You may be picking up interference.

[thagrol]

is there something i muissed in this case

Did you configure as apropriate pull resistor on the GPIO? Or add an external one?

Without a pull resistor the pin will be floating and you'll get random states while the button is unpressed.

If the buton is active when the GPIO input see a low state you need a pull up to 3.3v (or use the internal one). Refer to the docs for your chosen GPIO library for how to set that.

[alix2341]

Do you have a pull - up on the gpio pin you are using for input so that operation the switch pulls it down to ground ?

I wasn't using that at first but then after reading I'm using a Pull-up Circuit with two resistors but it still shorted after one hour and at this moment not sure why again.

[alix2341]

How long are the wires to your switch? You may be picking up interference.

Not that long I guess like 15 cm of cable

[ame]

Do you have a pull - up on the gpio pin you are using for input so that operation the switch pulls it down to ground ?

I wasn't using that at first but then after reading I'm using a Pull-up Circuit with two resistors but it still shorted after one hour and at this moment not sure why again.

What?

[alix2341]

Best thing would be to post a photo of what you did (and post a simple version of the software); latest point is not likely to be the origin of transients, but it may avoid further horrors.

So basically I did it like this but in a more crappy way since i don't have the breadboard


I'll try and send a more accurate image once I'm back
and this the code I'm using

Code: Select all

import RPi.GPIO as GPIO
import time
import subprocess

BUTTON_PIN = 17  # Change this to the GPIO pin you connected the button to this is can be customised
APP_COMMAND = "sudo pwsh /fire/buttonchecker.ps1 > /fire/log.txt"
def button_callback(channel):
    print("Button pressed, launching application...")
    subprocess.Popen(APP_COMMAND, shell=True)

GPIO.setmode(GPIO.BCM)
GPIO.setup(BUTTON_PIN, GPIO.IN, GPIO.PUD_UP)

GPIO.add_event_detect(BUTTON_PIN, GPIO.FALLING, callback=button_callback, bouncetime=300)

try:
    while True:
        time.sleep(1)

except KeyboardInterrupt:
    print("Exiting...")

finally:
    GPIO.cleanup()

[pcmanbob]

If you are pulling the gpio pin up then you should not really be worried by interference being picked up by your wires as you already have a high state on the gpio pin which only goes low when the button is pressed. ( interference is very unlikely to cause a low state on the gpio pin )

It may be that your circuit does not accurately match the diagram , best to post a picture of what you actually have.

[alix2341]

Forgive the crappy setup its still a work in progress

[pcmanbob]

Well from the image it looks correct if you have the 10K resistor conned to the 3.3V pin and the 1K resistor connected to the GPIO pin, cant check if you are on the correct pins as I cant see that from your image.

But your connections leave a lot to be desired, so you may have a poor or intermittent connection on any of those wires / connections which might be causing your problems .

I would recommend you get a bread board for experimentation or at lease solder the connections to the resistors.

[davidcoton]

I have a button connected to the RP4 board and using this kind of switch https://www.giovenzana.com/component/pcw01/ and a button, everything works fine except the fact that the script sometimes run at random times as if the button is clicked even though its not (I checked that by adding a flag when the button is clicked in the python script) I'm using the GPIO 17 and a ground pin on the board only those two, and the python script works fine its just the random clicking is there something i muissed in this case

[Emphasis added]
Does that mean that the script is launching without the Python code reporting the button press?
If so, the problem is highly unlikely to be with the hardware, but probably something else in the Pi is launching the script.
Have you ever tried to launch the script any other way? What is in the script -- possibly an hour-long "delay and repeat"?

[davidcoton]

What is in the script -- possibly an hour-long "delay and repeat"?

Excuse me, but script is here :
viewtopic.php?p=2108837#p2108837

No, that is the Python program. It monitors the GPIO and launches a script:

Code: Select all

APP_COMMAND = "sudo pwsh /fire/buttonchecker.ps1 > /fire/log.txt"
...
    subprocess.Popen(APP_COMMAND, shell=True)

My question is, what does " pwsh /fire/buttonchecker.ps1" really do?
Maybe "fire/log.txt" has some clues?

[thagrol]

What is in the script -- possibly an hour-long "delay and repeat"?

Excuse me, but script is here :
viewtopic.php?p=2108837#p2108837

No, that is the Python program. It monitors the GPIO and launches a script:

Code: Select all

APP_COMMAND = "sudo pwsh /fire/buttonchecker.ps1 > /fire/log.txt"
...
    subprocess.Popen(APP_COMMAND, shell=True)

My question is, what does " pwsh /fire/buttonchecker.ps1" really do?
Maybe "fire/log.txt" has some clues?

Well, there's an obvious followup question to the above: does the directory /fire actually exist? It's not a standard sub directory of /.

Secondly, why is the OP trying to run what appears to be a windows powershell script (AIUI that's what .ps1 indicates) on a Linux system? Neither is there any sign of pwsh in the RPiOS repo.

[emma1997]

I would recommend you get a bread board for experimentation or at lease solder the connections to the resistors.

Solders are more solid than broad beards... and cheaper. (and soldred parts can be put on a broad beard)... Both (soldering for long term use, perhaps with an insulator coating, and broad beard for trials) seem necessary...

I agree that those plug boards are immensely inferior in terms of reliability and lifetime. Even the hundred dollar ones start failing soon enough. Specially after inserting different diameter leads. Peeling off the label and a touch of de-oxit buys a little time but before long...

I say this having traced literally hundreds of issues to this lame construction method (me back when young and foolish and more recently as school lab assistant). PCB or manhattan/dead-bug or even just twisting wires together much better IMO.

Usually you can separate the pros from the noobs by their choice of wiring. Although we got quite a laugh at local ham club perusing the original Pico user manual. Photos showing it sitting in a plug board w/NOTHING ELSE CONNECTED! So even supposed professional developers sometimes like to slum it. lol

As far as flaky buttons it's quite amusing to see how often external pullups and/or caps are recommended when that rarely fixes things. IME it's almost always a software bug or debounce issue not hardware. Here for example the GPIO3 dtoverlay trick has been shown to work reliably over several meters (not cm) with no sign of interference. In fact my security system runs hundreds of meters (did require some customization of button routines). That's with welding shop next door and myself building thousands of 18650 into packs w/cheapo Kweld clone. No false or missed alarms in 20 years.

As a quick test I recommend trying w/PIOS dtoverlay to rule out DIY code bugs or pin/wiring errors. Surprising how little long wires matter.

[ame]

I would recommend you get a bread board for experimentation or at lease solder the connections to the resistors.

Solders are more solid than broad beards... and cheaper. (and soldred parts can be put on a broad beard)... Both (soldering for long term use, perhaps with an insulator coating, and broad beard for trials) seem necessary...

I agree that those plug boards are immensely inferior in terms of reliability and lifetime. Even the hundred dollar ones start failing soon enough. Specially after inserting different diameter leads. Peeling off the label and a touch of de-oxit buys a little time but before long...

I say this having traced literally hundreds of issues to this lame construction method (me back when young and foolish and more recently as school lab assistant). PCB or manhattan/dead-bug or even just twisting wires together much better IMO.

Usually you can separate the pros from the noobs by their choice of wiring. Although we got quite a laugh at local ham club perusing the original Pico user manual. Photos showing it sitting in a plug board w/NOTHING ELSE CONNECTED! So even supposed professional developers sometimes like to slum it. lol

As far as flaky buttons it's quite amusing to see how often external pullups and/or caps are recommended when that rarely fixes things. IME it's almost always a software bug or debounce issue not hardware. Here for example the GPIO3 dtoverlay trick has been shown to work reliably over several meters (not cm) with no sign of interference. In fact my security system runs hundreds of meters (did require some customization of button routines). That's with welding shop next door and myself building thousands of 18650 into packs w/cheapo Kweld clone. No false or missed alarms in 20 years.

As a quick test I recommend trying w/PIOS dtoverlay to rule out DIY code bugs or pin/wiring errors. Surprising how little long wires matter.

Cool story, bro.

[emma1997]

Thank you very much for complementing me again on my acute insight.

As usual I'd love to reply with more greatly extended details on evils of plug boards or why button problems are due to incompetent code, not lack of strong pullups or other hardware kluges. But FBI is just around the corner so let's keep it brief:

I suspect there may be dozens of experts in the world out there who know the real story. DOZENS !!!

[ame]

Thank you very much for complementing me again on my acute insight.

The only thing missing was a discussion about wearing an onion on your belt.

As usual I'd love to reply with more greatly extended details on evils of plug boards or why button problems are due to incompetent code, not lack of strong pullups or other hardware kluges. But FBI is just around the corner so let's keep it brief:

I suspect there may be dozens of experts in the world out there who know the real story. DOZENS !!!

I think you'll find that the lack of a pull-up would certainly affect your implementation of the classic "pushbutton" input device, no matter how competent your code was.

[alix2341]

Excuse me, but script is here :
viewtopic.php?p=2108837#p2108837

No, that is the Python program. It monitors the GPIO and launches a script:

Code: Select all

APP_COMMAND = "sudo pwsh /fire/buttonchecker.ps1 > /fire/log.txt"
...
    subprocess.Popen(APP_COMMAND, shell=True)

My question is, what does " pwsh /fire/buttonchecker.ps1" really do?
Maybe "fire/log.txt" has some clues?

Well, there's an obvious followup question to the above: does the directory /fire actually exist? It's not a standard sub directory of /.

Secondly, why is the OP trying to run what appears to be a windows powershell script (AIUI that's what .ps1 indicates) on a Linux system? Neither is there any sign of pwsh in the RPiOS repo.

The powershell script runs perfectly, and yes i added pwsh to the RP (installed it from github)
/fire does exist its a directory i created

[alix2341]

Perhaps it does not do anything.
thagrol wrote (partial quote)

the script for now only detects the button press and reports it in the log file this is done to check when/why the button was sending the button press signal since the python script is always waiting for the button press, and NO the ps doesn't have a loop so it cant be the ps script

IF (I agree this a simple hypothesis: alias pwsh=bash is a very ugly solution to ruin my simple bet)
pwsh cannot execute OR does not even exist

no pwsh is an alias to run powershell in linux powershell 7.3.4 to be more specific, it does both it excutes and exists and I wanted to use it since im using some modules from powershell which was easier at the time to just complete the script in powershell and use it

Code: Select all

APP_COMMAND = "sudo pwsh /fire/buttonchecker.ps1 > /fire/log.txt"
...
    subprocess.Popen(APP_COMMAND, shell=True)

will send an error somewhere/nowhere, without interfering with python script (I hope I do not misread subprocess manual...);
previous line

Code: Select all

 print("Button pressed, launching application...") 

is executed, anyway and the while(1 == 1) loop will go on...
spurious weird levels keep on being detected

OP should, IMO

detect that the file to be executed exists, and is executable.
detect that the directorry receiving logs (can be different fro the place where scripts are: this is sane practice: if logs are too long, people often remove the whole directory) exists and is writable.

This could be done outside a forever loop... (at the beginning, after importing libraries).
What would happen if logs were witten on a removable device (USB) and device is removed while infinite loop is ongoing?

[emma1997]

The only thing missing was a discussion about wearing an onion on your belt.

Doh! I knew I forgot something.

I think you'll find that the lack of a pull-up would certainly affect your implementation of the classic "pushbutton" input device, no matter how competent your code was.

I was careful referencing terms like "external" and "stronger". No mention of none at all. Probably even most rank beginners realize the need for at least internal ones. My point is those are enough if code is correct. Probably the only real need for adding external is if you need pull-DOWN on an MCU lacking that ability or initialization issues. Unlikely w/Pi or Pico.

The difference between internal and adding a 10k is usually insignificant for reducing EMI. It has to do with line impedance which is in the order of 100r or so. To make any real headway reducing rf interference requires like 100r or 50r pullup which is not always practical. A 10k or even 1k rarely helps out here in the real world. Much better to fine tune debounce code which IME handles nearly every type of interference encountered w/o need for extra parts.

Anyway looks like OP is dealing w/tool or software bugs which I find to be the root for majority of flaky buttons.

[alix2341]

So after I got fed up with my electrical newbieness, I asked a colleague with electrical background for help, he took the pi from me added a few the resistors and soldered them correctly, shortened the wire so that they don't pick up interference, left it for more than 24h on and it seem to be fixed I'm gonna provide a more detailed picture of what he did.
For now it looks like its fixed, thanks for the insight everyone, it helped a lot.

[ame]

The only thing missing was a discussion about wearing an onion on your belt.

Doh! I knew I forgot something.

I think you'll find that the lack of a pull-up would certainly affect your implementation of the classic "pushbutton" input device, no matter how competent your code was.

I was careful referencing terms like "external" and "stronger". No mention of none at all. Probably even most rank beginners realize the need for at least internal ones. My point is those are enough if code is correct. Probably the only real need for adding external is if you need pull-DOWN on an MCU lacking that ability or initialization issues. Unlikely w/Pi or Pico.

The difference between internal and adding a 10k is usually insignificant for reducing EMI. It has to do with line impedance which is in the order of 100r or so. To make any real headway reducing rf interference requires like 100r or 50r pullup which is not always practical. A 10k or even 1k rarely helps out here in the real world. Much better to fine tune debounce code which IME handles nearly every type of interference encountered w/o need for extra parts.

Anyway looks like OP is dealing w/tool or software bugs which I find to be the root for majority of flaky buttons.

I guess we'll find out when more details are posted.

[emma1997]

Not necessarily. On the few occasions when I've seen adding an external pullup seemed to fixed things it turned out the internal one had not been activated or similar 'software' problems. After those corrections had been made it continued to work even after the external was removed. Like hundreds of threads similar to this one where many other changes were made but not tested individually.

I will also add that inserting a SERIES resistor can suppress interference on long wires. Input pin capacitance functioning as the c part of the filter. Therefor unlike the pullup situation the higher r the better. Specially 1k like shown earlier here will not allow hardly any rf to pass. A recent Pico user was wondering why he couldn't detect a high freq signal until a pointless 10k series was removed.

With my hundred meter plus runs, even though not required, a 220r series blocks everything from nearby welders and broadcast stations as seen on a scope. In my case the only real reason is protection from high energy events like lightening strikes or shorts circuits. Far more effective for interference than that pu myth but also rarely needed except protection for very long cables.

I have no idea what's going on software wise in this thread but will personally not be convinced adding pu with leads that short makes any difference at all. As long as internals are enabled that is. You are obviously free to continue with whatever belief system you choose.

[ame]

Not necessarily. On the few occasions when I've seen adding an external pullup seemed to fixed things it turned out the internal one had not been activated or similar 'software' problems. After those corrections had been made it continued to work even after the external was removed. Like hundreds of threads similar to this one where many other changes were made but not tested individually.

I will also add that inserting a SERIES resistor can suppress interference on long wires. Unlike the pullup situation the higher r the better. Specially 1k like shown earlier here will not allow hardly any rf to pass. A recent Pico user was wondering why he couldn't detect a high freq signal until a pointless 10k series was removed.

With my hundred meter plus runs, even though not required, a 220r series blocks everything from nearby welders and broadcast stations as seen on a scope. In my case the only real reason is protection from high energy events like lightening strikes or shorts circuits. Far more effective for interference than that pu myth but also rarely needed except protection for very long cables.

I have no idea what's going on software wise in this thread but will personally not be convinced adding pu with leads that short makes any difference at all. As long as internals are enabled that is. You are obviously free to continue with whatever belief system you choose.

By all means, keep digging.