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

Sensing doesn't work if both Switching and Sensing use the same GPIO pin. #182

Open
kantlivelong opened this issue Apr 16, 2021 · 4 comments

Comments

@kantlivelong
Copy link
Owner

kantlivelong commented Apr 16, 2021

After 1.0.0 some users using switching and sensing on the same pin can no longer do so. Expected with Python-Periphery because pins are configured as objects.

Workaround is to use Internal sensing. Will need to investigate long term solution.

@kantlivelong
Copy link
Owner Author

So this actually seems to have been a long running bug due to the way GPIO was configured. In previous versions with RPi.GPIO the sensing pin was setup then the switching was setup afterwards. This essentially overwrote the sensing pins direction from input to output but RPi.GPIO would still return a value.

@Markeno76
Copy link

Would feeding Switching Pin back to another GPIO Pin for Sensing be a suggested way to still use GPIO Sensing? Internal will make it functional for now for me, but I very often trigger a manual power up at the printer with the Enclosure Plugin. It seems if PSUControl doesn't think the printer is powered on that it will automatically power it down.

@kantlivelong
Copy link
Owner Author

Would feeding Switching Pin back to another GPIO Pin for Sensing be a suggested way to still use GPIO Sensing? Internal will make it functional for now for me, but I very often trigger a manual power up at the printer with the Enclosure Plugin. It seems if PSUControl doesn't think the printer is powered on that it will automatically power it down.

You can bridge an adjacent GPIO pin and use that sure.

@kantlivelong
Copy link
Owner Author

PSUControl-RPi.GPIO 1.0.2 has been released which brings this "bug" old behavior back.

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