node-red-node-pi-gpio GPIO reset to 0 when node red is stopped
Somebodyisnobody opened this issue · 10 comments
Which node are you reporting an issue on?
node-red-node-pi-gpio rpi-gpio out
What are the steps to reproduce?
- Simply set up the node, deploy
- Redeploy || restart nodered service || restart the pi
What happens?
The GPIO pin is being resetted to 0 (low state)
What do you expect to happen?
The GPIO should stay untouched as I don't see a reason for setting it to low state
Please tell us about your environment:
- Node-RED version: v2.2.2
- node.js version: v12.22.5
- npm version: 7.5.2
- Platform/OS: Linux smartpi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
- Browser: Chrome
Background / Use case: I am using the SmartPi 2 board from enerserve.eu. This board has a relais controlled by a digital GPIO port. The relais sets a contactor which in turn controls the power over my home. So I have a nice party here when rebooting the Pi.
I think I remember that in a previous version I was able to restart with such a setup without changing the GPIO pins.
Until fully booted and Node-RED fully running it has no control of the gpio pins. The underlying hardware and operating system may default them to certain values during boot but again that may not be reliable. You may find some info on which pins default to which value on boot via google etc, but it's nothing Node-RED can control.
Eg see https://roboticsbackend.com/raspberry-pi-gpios-default-state/
Oh i'm not talking about booting only. It's about stopping nodered (for example by rebooting the pi). Just stop the nodered service service nodered stop and the pin will be set from 1 to 0 without rebooting the pi.
I guess GPIOs are set over values in files. So when node red stops I suspect it to write a 0 into such a file for whatever reason.
As soon as you stop the Node-RED service it relinquishes control to the underlying OS. So nothing we can do.
So it's not just putting 0 or 1 into a file, it's more an exclusive access?
Not sure what you mean? What file ? Who is doing that ?
Sorry, i thought GPIOs are controlled by writing into a file unter /sys/class/gpio/... (https://www.elektronik-kompendium.de/sites/raspberry-pi/2202101.htm) If nodered stops the file wouldn't care about it so I wounder what do you mean with "it relinquishes control to the underlying OS". In meantime i took a look into https://github.com/node-red/node-red-nodes/blob/master/hardware/PiGpio/nrgpio.py. On my local system I removed (commented out) the GPIO.cleanup()-function. With this modification the GPIO didn't change when restarting node red with last state HIGH. But when the last state is LOW then the GPIO is set to HIGH until node red is restarted. So it's the completely opposite behaviour than without the modification where being in state HIGH causes the system to set the GPIO to LOW on node red restart.
Yes - that is one way they can be controlled.
The advice we followed when creating the node was to always use cleanup to avoid things like this https://raspberrypi.stackexchange.com/a/70694 . Of course you are free to remove that.
But either way - as soon a Node-RED exits (or while stopped before restart) we no longer have control so anything can happen.
Net is I don't think there is anything to fix here so I will close this as an issue.
I am fine with that, I found a solution with a latch logic IC