RPI-GPIO-IN not giving the expected output

I have setup four nodes using the RPI-GPIO-In nodes.
I am aiming at storing alarms into Influxdb. If the GPIO is High the function output "1" if GPIO is low the function output a "0".
The nodes work correctly when I inject the 0 or 1 from Nodered.
It doesn't work when the real physical high happens injecting 3.2 V to the pin. At time it works other times instead of one pin high the nodes give me multiple pins high. Something is wrong.

Here is my node:

[{"id":"cc08c4d980616d50","type":"rpi-gpio in","z":"4e4990f3.d4ada","name":"Digi1","pin":"33","intype":"tri","debounce":"1000","read":false,"x":210,"y":440,"wires":[["631ad68655357cb0"]]},{"id":"1b5a1b7ac77825e9","type":"rpi-gpio in","z":"4e4990f3.d4ada","name":"Digi4","pin":"15","intype":"tri","debounce":"1000","read":false,"x":210,"y":860,"wires":[["e00a34770df4768c"]]},{"id":"eff3f759c2e735d7","type":"rpi-gpio in","z":"4e4990f3.d4ada","name":"Digi3","pin":"13","intype":"tri","debounce":"1000","read":false,"x":210,"y":720,"wires":[["ce490c93d11a0064"]]},{"id":"19d8e7f9151ccdd6","type":"rpi-gpio in","z":"4e4990f3.d4ada","name":"Digi2","pin":"11","intype":"tri","debounce":"1000","read":false,"x":210,"y":580,"wires":[["0ff9ad772d22ebea"]]},{"id":"ec5eed2580800251","type":"debug","z":"4e4990f3.d4ada","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":510,"y":400,"wires":[]},{"id":"631ad68655357cb0","type":"function","z":"4e4990f3.d4ada","name":"","func":"var D= msg.payload\nmsg.payload={\"Digi1\": D};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":340,"y":440,"wires":[["ec5eed2580800251","7642286748afd7c9","4b48f8c4ecf91f7a"]]},{"id":"0ff9ad772d22ebea","type":"function","z":"4e4990f3.d4ada","name":"","func":"var D= msg.payload\nmsg.payload={\"Digi2\": D};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":340,"y":580,"wires":[["70e8097fbf8cf778","67ee41c72c281da5","2359fb37468b4149"]]},{"id":"ce490c93d11a0064","type":"function","z":"4e4990f3.d4ada","name":"","func":"var D= msg.payload\nmsg.payload={\"Digi3\": D};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":340,"y":720,"wires":[["c935a383d24b16c6","b90190576a86f390","e862f4066071b713"]]},{"id":"e00a34770df4768c","type":"function","z":"4e4990f3.d4ada","name":"","func":"var D= msg.payload\nmsg.payload={\"Digi4\": D};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":340,"y":860,"wires":[["86475015814e3835","4d2280e842b3a856","90148ce2bdcaa22b"]]},{"id":"67ee41c72c281da5","type":"debug","z":"4e4990f3.d4ada","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":490,"y":540,"wires":[]},{"id":"b90190576a86f390","type":"debug","z":"4e4990f3.d4ada","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":510,"y":680,"wires":[]},{"id":"4d2280e842b3a856","type":"debug","z":"4e4990f3.d4ada","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":490,"y":820,"wires":[]},{"id":"47fc6e50e6153506","type":"inject","z":"4e4990f3.d4ada","name":"","props":[{"p":"payload"},{"p":"topic","v":"1","vt":"num"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"1","payloadType":"num","x":70,"y":660,"wires":[["631ad68655357cb0","0ff9ad772d22ebea","ce490c93d11a0064","e00a34770df4768c"]]},{"id":"81e917c6a831d839","type":"inject","z":"4e4990f3.d4ada","name":"","props":[{"p":"payload"},{"p":"topic","v":"0","vt":"num"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"0","payloadType":"num","x":70,"y":620,"wires":[["631ad68655357cb0","0ff9ad772d22ebea","ce490c93d11a0064","e00a34770df4768c"]]}]

Do I need to setup the 4 GPIO with a Python script as input before using the GPIO node?

What is the hardware driving the pin?
Does it drive high and low or just high?
Have you got an external pullup or pulldown resistor?

Feed the GPIO node direct into a debug node and show us what you see in the debug pane when the problem occurs.

Don't forget to answer all the questions please.

[Edit] Just one of the pins please and disable any other debug so we can see what is happening.

Colin, thanks for supporting on this issue.I am using a simple relay normally open for each of the four pins. If there is an alarm the contact close and the 3.2V from the raspberry PS bus is then directly injected to the GPIO.
So, this basically drives the pin high. The low (grounded) is something I have not considered yet.
I do not have any resistor in the external circuit. It is just straight 3.2 V to the pin.

In the picture here below you see all 4 pins when I inject 0 from nodered and then when I inject 1. As I said, from nodered it works perfectly. The problem happens when I use the hardware.

Schermata 2021-09-16 alle 18.16.35

And this is the output when I inject the 3.2 V physically into Digi2.
I have checked the wiring and I can confirm that the connection goes directly from the relay to the pin. There is no short circuit between the two inputs (2 and 4).
At time will even trigger the 3rd input. Other times just the one injected.

We need to see the output when it fails. Also please connect the debug direct to the GPIO, as asked. Also disable all the all the other debug so only the one is seen.

However, before you do that you need to add a pulldown resistor. As you have it the input is floating when you are not driving it so anything can happen. The merest pickup on the input wire may trigger the pin. Preferably connect something like a 4k7 resistor to 0v externally. As a test you could enable the internal pulldown in the gpio node config. That will help a lot but it is still preferable to have an external pulldown.

1 Like

I am 50 km away from the hardware but I will try to follow your directions in the morning and let you know. Thanks a million for now. Will post the results in 16 hours.

Did you add the extra image after posting the first one? I didn't see it the first time.
I didn't realise you meant that there is cross coupling between the inputs, I thought you meant extra pulses on the driven input. As I said you can test it out using the internal pullup, assuming you have remote access to node-red.

I don't think I can set the internal pull-up or down from the node because a message pops out saying that the pin is already set as tri. !?

I will do it physically in the morning.

If you deploy it with pulldown enabled does it show an error?

Before jumping in the car to go on site to physically access the device I did set the pulldown resistor on the nodes. That message popped out again but I noted that there were no errors after deploying.
It is working fine now. With the pull down resistor set in the node, the behaviour of the pin is as expected and even the cross coupling disappeared.
Thanks a million for guiding me to the solution of the issue. Really appreciated.

Do you know what that pop out message (Pin xx already set as tri) means?

Tri-State - AKA Floating - AAKA no HIGH or LOW pullup/down present. May associate with a pin that hasn't been set yet for input or output? (just a guess there) Google for more :slight_smile:

In this case the pin had been configured as an input, without pullup/down. The message apparently appeared when it was changed to pulldown, which seems odd to me.

I would still add an external pulldown when convenient. The internal is good enough if the pin is connected to something onboard but if you have external wiring connected it is always a good idea to add an external one.

Thank you Colin. Will do.
After adding the external pull down resistor, I assume I should not use the internal one. Correct?

1 Like

Yes, I knew about it being an input... I was just answering the "what is tri" question.

Also, after some playing around on my end, I see similar messages such as is already set as tri, already set as up, etc. when setting pins as input with other output nodes already configured. So I think it is simply a "FYI" warning not to mess up a GPIO set as output by accidently also trying to make it an input, and possibly vice versa. Although I haven't found anything about such an warning msg in the node-red-node-pi-gpio notes...

EDIT... found this in the HTML. So yes, it is a msg indicating that the GPIO referenced already has no pullup or pulldown assigned.

<option value="tri" data-i18n="rpi-gpio.resistor.none"></option>

Leave the internal one on. Then if the wire drops off at least you are guaranteed what state it will be in.

So does that appear whenever a node is changed from tri-state to pullup/down? It seems odd to show something which looks like an error for that.

It seemed to show whenever I was setting up a GPIO IN node, when choosing the resistor option.

I didn't want to totally mess up my existing output GPIO pins used with MQTT stuff (but did manage to do so :stuck_out_tongue: thankfully simply requiring resetting the GPIO OUT node), so I didn't play around much more than confirming the msgs.

I agree that pop-up message with the red band is a bit misleading.

Can someone post a screenshot of the message so we know exactly which one. Thanks

Post #7 above