That is talking about the Pi 5 showing a problem that does not exist on the 4. This is a Pi 4.
You are absolutely right. No point testing it then.
Another 2 years under LTS support
https://www.debian.org/releases/bullseye/
OK - I have managed to borrow a Pi5 and flashed a new SD card with latest 64bit Bookworm.
Booted - installed latest OS updates... then ran the install script with no extra parameters, said yes to adding Pi nodes... that installed node 20.16.0 and Node-RED 4.0.2 - started Node-RED and added a small flow to write 1 or 0 to a pin with an LED attached... and yes... it works...
That's a surprise!
I'll update my Pi5 and see how it goes
Indeed I was surprised also... was just settling in for a long head scratching debug session...
Note mine was a fresh SD flash. not upgrading an old version. (Was the default desktop version... I'll redo again now with the minimal version)
The problem the OP has is on a 4 not a 5.
Ah yes - sadly I only have Pi 0,0w,1,2,3 and now (for a short time) a 5...
GPIO on bookworm works ok on a 3 (and now 5) so I'd be surprised if 4 was really that different... but hey ho.
(of course I'd be happy to swap a couple of Pi 2s for a 4 as 2+2=4 )
So would I, I suspect it is something different about the OP's system.
@mima232, how did you do the update?
I re-installed plain vanilla Bookworm 64 bit desktop and my pins work as well
I'm thinking that they must be including the python3-rpi-lgpio drop-in replacement as standard nowadays
@mima232
If you just run python from a terminal
then type
import RPi.GPIO as GPIO
GPIO.VERSION
what do get?
I get 0.7.2
If everything works, can I delete my node?
Well it's up to you - but you do have a bunch of extra features and capabilities in your version that the default nodes do not - so I think they would be useful for users.
@Colin by system update I mean complete fresh installation with my install script
on my machines I use the Lite version ... idk if it could be different then the Desktop one
@cymplecy when I run that python commands it also returns me version '0.7.2'
I will try once more clean image and try to install manually only nodered to eliminate possible influence of the script
The official script is the best way to install node-red
I've got one more idea ... is there any problem with using multiple gpio nodes with same selected pin? And with pin state init?
@cymplecy yes, I use the official install script but also do other stuff in system
especially I am concerned about this part:
sudo sh -c 'echo "4" > /sys/class/gpio/export'
sudo sh -c 'echo "out" > /sys/class/gpio/gpio4/direction'
sudo sh -c 'echo "0" > /sys/class/gpio/gpio4/value'
which I use to trigger pin from bash script ... or have used, because in Bookworm it cant be used anymore
Yes, I do seem to remember issues reported with 4.0 and multiple gpio nodes on the same pin. I suspect that only ever worked by accident rather than design.
Indeed it is the issue. I did fresh install with manual NR installation without my script. When I used only one node to control the pin, it was ok. When I copied the flow, the second pi node wrote status stopped and when I try to send pin state to it, status changes to not running and the "nrgpio python command not running" error shows up.
I tried it back on the Bullseye, no error shows, but the pin control does not work properly.
Quickly checked the pi node page, but there is no info about using multiple instances of same pin.
So the only solution to this is using link nodes to single instance?
Or via MQTT or similar.
Yes - that has always been the case (even if for some reason it didn't complain). In my (hardware) engineer head I always had a model that the node was the physical pin itself so while I could wire multiple things to one "pin" - I could not have multiple of the same one.
Ok, I expected that the node only calls some function or script with pin and state as parameter.
Thanks everyone for help, testing and your time!