Node-RED version: v4.0.8
Node.js version: v20.19.0
Linux 6.12.20-v7+ arm LE
Hello. I am having an issue where NodeRED will seemingly at random stop reading any changes in Raspberry Pi input nodes. Restarting NodeRED fixes the issue, and while the issue is happening the gpio read command correctly shows the input pin state.
This happened with the default RPi nodes, so I thought I could try using some other package and installed pi-gpiod instead, but the exact same thing happens.
I also restarted the pigpiod service while this issue was happening, and it also didn't help. It seems like the problem is with NodeRED itself, but there is nothing in the logs and no error is shown when restarting it. It simply hangs with the input always being read as 1, regardless of what the input actually is and what gpio read reports.
The most used GPIO packages for NodeRED all seem to have not been updated in a while, is there some that is considered more up-to-date that I could try? Or, because the exact same thing happened with node-red-pi-gpio as well as node-red-pi-gpiod, should I expect it to be persistent no matter which package I choose?
EDIT: I should also mention that this is a Raspberry Pi 3, I also have a project based on a Raspberry Pi 2 where I thought GPIO worked fine, but recently I came back to it only to see the GPIO input node associated with a hardware button cycling between 1 and 0 on its own, even though nobody was touching the button. In this case I just restarted the whole system without debugging because I needed it to work ASAP, so I am not sure if it is the same problem where gpio read would have shown the correct real value
It is a Raspberry Pi 3B+, os is reported as Linux 6.12.20-v7+ arm LE. There is no output coming from the node when this happens, it also has an indicator in the UI showing its status and that too remains unchanging. When it happens next time I will try observing the log. And yes, the rest of the flow works without problems, which is why I find this unusual, because everything behaves as if there was absolutely no issue, the GPIO input just stops updating.
I am still trying to figure out if there is anything specific that triggers this issue. The problem is that it's so "silent" that at some point I just notice the inputs stopped updating, but I have no way of knowing how long that has been the case. It could have happened on its own overnight, or maybe when I was doing something with the RPi the previous day.
The pins are configured as pull-up, and just are a simple push button switch to ground. But as mentioned the RPi itself can see their state correctly even when the node doesn't. In theory I could write some python script to monitor the GPIO and relay that information to NodeRED, but if possible I would just like to use the proper solution through the gpio input nodes.
I am using two buttons, and both of their associated pins are always affected together.
I suspected it just happens randomly whenever the flow is redeployed, so for about a minute all I did was move the position of a node in the editor and redeploying it over and over again. Literally nothing else has changed, just the position of a node in the editor being moved left and right.
I executed node-red-log, and there are no errors or warnings or anything, nothing to suggest anything is wrong, the input nodes just don't work while the rest of the flow runs fine.
I was moving a Link In node unrelated to the GPIO functionality, but the deployment is set to do Full Deploy always. I can set it to only deploy modified nodes (there is only one flow on this device), but I am not sure that is a good solution, as I would like to figure out why a full deploy would cause the GPIO inputs to just stop working in the first place. The buttons were also not touched, so the GPIO nodes were not actively updating their status.
Maybe it could be that the GPIO nodes "sample" the gpio status every so often, and when the deployment happens to land on the exact same time something goes wrong? That's about the only way I can explain the randomness of this
I wasn't suggesting that as a solution (but it is a good idea to only deploy modified nodes, it is much quicker).
So, effectively, restarting the flows appear to sometimes cause the gpio nodes to lockup. I don't remember any others having such problems so it must be something to do with your system.
Are you now using the standard node-red GPIO nodes and have you removed any additional stuff related to GPIO that you installed?
I am using node-red-node-pi-gpiod currently, and I have removed the default node-red-node-pi-gpio. I can try going back to the standard, but I think the exact same thing is going to happen because when it locked up the first time, it was with the standard GPIO nodes.
I think I will try node-red-contrib-johnny5, which seems to be using a different approach to read from GPIO and maybe won't be affected by this issue?
This is an otherwise clean install of the OS, and image I made to flash RPis which only has the basic settings done plus NodeRED installed.
Oct 2023...
But I didn't suggest upgrading, I asked a question.
If I recall correctly, Bookworm was when the gpio stuff was rewritten for the pi5 hardware changes.
It is 32-bit RPi OS, downloaded as the latest that was up around this February, except it is the legacy image.
The reason for this is that I need the same system image to work on RPi 2 computers, and for those the standard image is unusable, they become too slow and unresponsive. Other than that there was no specific decision to avoid Bookworm.
In use are pins GPIO04-7 and GPIO22-15. No external resistors are present.
I do not have the pinctrl command available, even though I do have raspi-utils installed. I will look into compiling it so I can try getting its output during the next failure.
I'm not really sure but I assume pinctrl was introduced as part of the Pi5 hardware and RPiOS Bookworm changes so no surprise it's not available in the Legacy OS.
I don't have any Pies running that OS version so I can't check if it even works.
Nothing special about this tool, just that it gives comprehensive data and as a CLI tool it's easy to use.
FWIW this is on a Pi4 (with Bookworm, 64 bit):
pi@AlsoPi:~ $ pinctrl -v -p 7,15
GPIO chips:
fe200000: bcm2711 (58 gpios)
7: ip pu | hi // GPIO4 = input
15: ip pd | lo // GPIO22 = input
It's a replacement for raspi-gpio, which I've never used.
Anyway, it would be interesting to see if OS level tools always agree with Node-red's GPIO nodes, which might suggest a problem with the hardware, or if they still work when NR gets out of sync, implying a bug in the GPIO nodes.
I suspect the latter but without any good evidence.
Evidence against that is that I don't recall any other instances where this symptom has been reported. If it is a problem with the nodes then that would suggest a recently introduced bug.
I don't currently have any systems using GPIO Inputs so I can't easily test it myself.
On the other hand @derek is actually seeing the problem in an unusual situation. That of using Full Deploy. The vast majority of users, I assume, use Modified Nodes deploy, and I assume that the problem will not exhibit itself in that situation.
@derek can you see if you can repeat the problem using just Modified Nodes for the deploy mode.
In fact, looking back at the thread, it can't be the GPIO nodes as the problem is seen with both standard GPIO nodes and the gpiod nodes.
