Node-red-node-pi-gpiod unreliable results

Hi there,

I'm using Raspberry Pi 4 and running two instances of node-red. One is installed as a docker container and the other is a standard installation on the Raspberry Pi.

I'm having an issue with the node-red-node-pi-gpiod node. I was using the docker container instance to collect data and transmit it via MQTT. One of the pins was used to define the window of interest by switching between high and low states, and this was working perfectly until I recently updated the standard node-red installation. After running the npm install command, the gpiod node became unstable.

I'm able to get consistent results on pin 37, which is being used by another input, and I can read the changing state from both the docker container and the standard node-red instance. However, pin 33 and pin 35 are only picking up the changing state occasionally (about 1% of the signals are captured correctly).

I've verified the trigger signal with an oscilloscope and it's consistent and unchanged from before.

I'm looking for advice on how to approach this issue and any ideas on what might be causing it.

Thank you for your time and help!

If you don't run the docker instance, does the main Pi instance report pin states correctly (via that gpiod node)

Hi,

Thank you for your suggestion. I tried that, but killing the docker container did not make a difference. I am still unable to read PIN33 in my stand-alone installation of node-red reliably. However, I can read PIN37 in both the docker container and stand-alone installations.

I have also tried switching between two different inputs (PIN33 and PIN35), but I am still encountering mixed results with the status change detected on these pins occasionally. The inputs are optoisolated with a custom PCB as a hardware interface.

Is there any other solution or suggestion you can offer to resolve this issue?
How to approach debugging?

Does it work if you use the standard GPIO nodes?
How fast is the input changing?

Hello @Colin

I had uninstalled the standard GPIO library and switched to the GPIOD due to issue with using the stndard GPIO library with docker and standalone instalation at the same time.

Regarding the input, it is changing relatively slowly, with a high state of approximately 0.5 seconds. I am not sure about the rate of change for the rising and falling edges.

I am unable to determine the reason for the discrepancy in functionality between the two inputs, PIN37 and PIN35.

Are you accessing pins from another application at the same time?

Hi,
I'm accessing pins only from Node-Red, but from two instances at the same time, however, the PIN35 is only used by the docker instance.

Try stopping the other node-red instances to make sure it is not a conflict.

How long is the low state?

What are you driving the input with and what circuitry are you using?

You didn't answer whether it works with the standard GPIO nodes (with only one node-red active obviously).

Hello @Colin,

Please see my responses below to your previous questions:

What is the duration of the low state?

The duration of the low state is approximately 1 second.

What is the method of driving the input, and what circuitry are you using?

The input is being driven by a PLC digital output, and the circuitry being used is standard.

You did not address whether the standard GPIO nodes are functional (with only one Node-RED active).

I had uninstalled the standard GPIO modules from Node-RED and have been using GPIOD instead. However, I can read from pin37 on both instances, but nothing on pin35 in either. Additionally, the signal on pin37 is generated by the PLC digital output and is faster. It stays high for approximately 25ms, then low for about 1 second or more. It is worth noting that this setup was functional before the update.

Sorry, but that is meaningless. What sort of digital output? Relay? Open collector 5V? TTL?
What 'standard' circuitry is that?
You said you verified it with scope, what high and low voltages are you seeing and is that at the Pi pin?

You didn't answer the suggestion that you try stopping the other node-red instance.

You still haven't answered the question, does it work with the standard GPIO nodes. You told us it did before the upgrade, but not whether it still works that way.

Certainly worth noting, but co-incidence regularly causes confusing symptoms.

Could you clarify exactly what you updated please? It is not clear.

Hello @Colin

My setup for both the stand-alone and docker container Node-Red instances was previously functional with the node-red-node-pi-gpiod node. However, after running npm install on the stand-alone Node-Red directory, I discovered that the node-red-node-pi-gpiod node had been replaced with the standard gpio module "node-red-node-pi-gpio": "^2.0.5" in the package.json file.
This caused issues, so I attempted to fix it by updating the package.json file of the stand-alone installation and replacing node-red-node-pi-gpio with node-red-node-pi-gpiod and running npm install again. However, since then, the system has been malfunctioning.

How did you switch to using gpiod? Did you do it purely by using npm commands or did you do something manually with package.json or the node_modules folder? The fact that npm changed what was installed suggests that it was unaware of a change you had made, and reverted it. You should virtually never manually edit the package file or manually change anything in node_modules.

You should just have used
npm remove node-red-node-pi-gpio
npm install node-red-node-pi-gpiod
It is possible that something is not installed, or uninstalled, correctly.
Did you manually change files in the container version, or did you do that by the book?
Show us what you now have in package.json for your non-docker version.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.