Pi GPIO input works on PiZeroW but on on Pi2

#1

I’ve done a simple flow to interface a PIR, its been working great on a PiZeroW for quite some time. Today I went to add the flow to a Pi2 system. I exported the flow on the PiZeroW and imported it into the Pi2. Problem is it doesn’t work when deployed. Running the latest Raspbian with: python-rpi.gpio is version (0.6.3~stretch-1).

The pin numbers are the same and I’ve verified the hardware works by hooking up a meter to the PIR output pin 0 volts when idle, 3.3V on detect.

Here is my flow, exorted from the Pi2 system:
[
{
“id”: “167e391a.96b117”,
“type”: “debug”,
“z”: “4b76ad62.77a454”,
“name”: “”,
“active”: false,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “true”,
“x”: 1010,
“y”: 100,
“wires”: []
},
{
“id”: “8ae1a316.ac03a”,
“type”: “rbe”,
“z”: “4b76ad62.77a454”,
“name”: “”,
“func”: “rbe”,
“gap”: “”,
“start”: “”,
“inout”: “out”,
“property”: “payload”,
“x”: 260,
“y”: 180,
“wires”: [
[
“ec0261ae.24e84”
]
]
},
{
“id”: “7dd4fa25.9ce844”,
“type”: “mqtt out”,
“z”: “4b76ad62.77a454”,
“name”: “PiCam PIR sensor”,
“topic”: “AI/PiCam_PIR”,
“qos”: “0”,
“retain”: “”,
“broker”: “8cadb95d.3521d8”,
“x”: 1090,
“y”: 160,
“wires”: []
},
{
“id”: “52b13145.efa49”,
“type”: “change”,
“z”: “4b76ad62.77a454”,
“name”: “”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “Motion”,
“tot”: “str”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 780,
“y”: 160,
“wires”: [
[
“167e391a.96b117”,
“7dd4fa25.9ce844”
]
]
},
{
“id”: “82f3461.35263b8”,
“type”: “change”,
“z”: “4b76ad62.77a454”,
“name”: “”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “Stopped”,
“tot”: “str”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 780,
“y”: 200,
“wires”: [
[
“167e391a.96b117”,
“7dd4fa25.9ce844”
]
]
},
{
“id”: “ec0261ae.24e84”,
“type”: “trigger”,
“z”: “4b76ad62.77a454”,
“op1”: “1”,
“op2”: “0”,
“op1type”: “num”,
“op2type”: “num”,
“duration”: “5”,
“extend”: true,
“units”: “s”,
“reset”: “”,
“bytopic”: “all”,
“name”: “”,
“x”: 420,
“y”: 180,
“wires”: [
[
“b57484f.9f74978”
]
]
},
{
“id”: “b57484f.9f74978”,
“type”: “switch”,
“z”: “4b76ad62.77a454”,
“name”: “”,
“property”: “payload”,
“propertyType”: “msg”,
“rules”: [
{
“t”: “eq”,
“v”: “1”,
“vt”: “num”
},
{
“t”: “eq”,
“v”: “0”,
“vt”: “num”
}
],
“checkall”: “true”,
“repair”: false,
“outputs”: 2,
“x”: 590,
“y”: 180,
“wires”: [
[
“52b13145.efa49”
],
[
“82f3461.35263b8”
]
]
},
{
“id”: “10eaae18.22a1e2”,
“type”: “rpi-gpio in”,
“z”: “4b76ad62.77a454”,
“name”: “PiCam PIR”,
“pin”: “7”,
“intype”: “tri”,
“debounce”: “25”,
“read”: true,
“x”: 100,
“y”: 180,
“wires”: [
[
“8ae1a316.ac03a”
]
]
},
{
“id”: “8cadb95d.3521d8”,
“type”: “mqtt-broker”,
“z”: “”,
“name”: “localhost:1883”,
“broker”: “localhost”,
“port”: “1883”,
“clientid”: “”,
“usetls”: false,
“compatmode”: true,
“keepalive”: “60”,
“cleansession”: true,
“birthTopic”: “”,
“birthQos”: “0”,
“birthRetain”: “false”,
“birthPayload”: “”,
“closeTopic”: “”,
“closePayload”: “”,
“willTopic”: “”,
“willQos”: “0”,
“willRetain”: “false”,
“willPayload”: “”
}
]

I was not expecting any issues here :frowning:

#2

When you say it doesn't work, what do you mean? If you attach a debug node to the output what do you see? If nothing, what do you see if you add a catch node connected to a debug node?

#3

The only thing that comes out of an added debug node is the read on startup value after I deployed:
7/6/2018, 8:31:03 AMnode: 33b3d125.3c5ffe
pi/7 : msg : Object
object
topic: "pi/7"
payload: 0
_msgid: "ae0ae82f.51f518"

Then the gpio node displays a red "stopped" icon below it on the webpage.

I'll followup again once I've figured out the catch node, I've got to do other things until this afternoon.

I'm mystified here.

#4

Two questions, first my standard response for a pi, have you updated to the latest version using the bash <(curl script?

Second restart node-red and paste the log here (run node-red-log to see the log if it is not visible in the terminal). You can use Ctrl+Shift+C to copy from the terminal, in case you don't know.

#5

Indeed - does the existing user have access to the gpio pins ? (which the script should fix if not)
the user should be in the group gpio - if you type the command groups it should show you.

#6

Adding the "catch all" node and wiring it to debug showed absolutely nothing. The GPIO pin is read initially as the checkbox to read initial state is checked and the downstream nodes respond as intended. But after that the icon changes to the red "stopped".

default user is member of gpio
pi@PiCam:~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi

I believe this is default for recent Raspbian stretch images.

I don't run the update script because it breaks the node-red-contrib-ftp-server node. Although I don't need it in this particular usage, I want to stay as close to the Raspbian distribution as I possibility can. I will check, but this should be the same version of node-red and node-js as on the PiZeroW I "imported" it from.

On Github the author of node-red-contrib-ftp-server has forked ftpd and make his node work with nodejs 8.x, its reported to work by the other issue reporter on Github. I will try it eventually but at the moment with the system needing the ftp node I'm in "if it ain't broke, don't fix it!" mode has the code has been running fine 24/7 for a couple of weeks now.

As to restarting node-red. The log looks pretty uninformative:
Starting as a systemd service.
Started Node-RED graphical event wiring tool.
6 Jul 12:16:05 - [info]
Welcome to Node-RED

6 Jul 12:16:06 - [info] Node-RED version: v0.18.7
6 Jul 12:16:06 - [info] Node.js version: v4.8.2
6 Jul 12:16:06 - [info] Linux 4.14.34-v7+ arm LE
6 Jul 12:16:07 - [info] Loading palette nodes
6 Jul 12:16:13 - [info] Dashboard version 2.9.4 started at /ui
6 Jul 12:16:17 - [info] Settings file : /home/pi/.node-red/settings.js
6 Jul 12:16:17 - [info] User directory : /home/pi/.node-red
6 Jul 12:16:17 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable
6 Jul 12:16:17 - [info] Flows file : /home/pi/.node-red/flows_PiCam.json
6 Jul 12:16:17 - [info] Server now running at http://127.0.0.1:1880/
6 Jul 12:16:17 - [warn]

Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.

6 Jul 12:16:17 - [info] Starting flows
6 Jul 12:16:18 - [info] Started flows
6 Jul 12:16:18 - [info] [mqtt-broker:localhost:1883] Connected to broker: mqtt://localhost:1883

I just checked, the PiZeroW is node-red v18.5. One of the first things I did before asking was delete the imported GPIO node and drag a fresh one from the 18.7 node-red pallet and configure it, made no difference,

I might try the upgrade scrip on this Pi2 if no other ideas are forthcoming since I don't need the ftp server here.

#7

I have a question about this statement in the doc about the upgrade script:
"Note: Once you have used this script to upgrade, you cannot use apt-get to upgrade the pre-installed version of Node-RED."

Does this mean apt-get dist-upgrade could have issues if the Raspbian folks update their version of node-red?

#8

It deletes the originally installed one so you will be fine.

#9

Thanks, maybe the comment on the documentation site could be clarified, as it sounds a bit ominous as it is.

To follow up on the original purpose, I ran the upgrade script and the GPIO node still doesn't work after restarting node-red. Exact same symptoms it fires once initially and then displays the stop icon. The catch all node I added doesn't catch anything.

I'm still stumped.
:frowning:

I'm not seeing the gpio nodes in manage pallet (or I'm not recognizing the package name) could this be part of the problem?

#10

The pallete only shows additional nodes that you can install, the gpio nodes are included in node-red so do not appear. I presume they do appear in the node panel on the left?

Is this correct - The GPIO In node shows Stopped but a catch node doesn't catch anything and there is nothing in the debug pane and nothing unexpected in node-red-log?

#11

What version of python is default ? python --version ?

#12

Yes that is exactly right. The GPIO nodes are shown in the left hand pane and the catch node never sends any messages. The downstream code runs once on deploy.

I just moved a node and clicked deploy, the GPIO input node connected, turned green, read the initial zero value (pulldown set) and then went to "stopped"

The startup after the upgrade looked normal to me:

Starting as a systemd service.
Started Node-RED graphical event wiring tool.
7 Jul 08:25:10 - [info]
Welcome to Node-RED

7 Jul 08:25:10 - [info] Node-RED version: v0.18.7
7 Jul 08:25:10 - [info] Node.js version: v8.11.3
7 Jul 08:25:10 - [info] Linux 4.14.34-v7+ arm LE
7 Jul 08:25:12 - [info] Loading palette nodes
7 Jul 08:25:18 - [info] Dashboard version 2.9.4 started at /ui
7 Jul 08:25:20 - [warn] Missing node modules:
7 Jul 08:25:20 - [warn] - node-red-contrib-camerapi (0.0.35): camerapi-takephoto
7 Jul 08:25:20 - [info] Removing modules from config
7 Jul 08:25:20 - [info] Settings file : /home/pi/.node-red/settings.js
7 Jul 08:25:20 - [info] User directory : /home/pi/.node-red
7 Jul 08:25:20 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable
7 Jul 08:25:20 - [info] Flows file : /home/pi/.node-red/flows_PiCam.json
7 Jul 08:25:20 - [info] Server now running at http://127.0.0.1:1880/
7 Jul 08:25:20 - [warn]

Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.

7 Jul 08:25:20 - [info] Starting flows
7 Jul 08:25:21 - [info] Started flows
7 Jul 08:25:21 - [info] [mqtt-broker:localhost:1883] Connected to broker: mqtt://localhost:1883

#13

Python 2.7.13 (default, Nov 24 2017, 17:33:09)

python-rpi.gpio is version (0.6.3~stretch-1).

Other than all the extras I had to install to compile openCV 3.3.0 my goal was to keep to as stock a version of Raspbian as possible, although I've been pretty regular at running apt-get dist-upgrade.

#14

yes - that is the weird thing - it looks like for some reason the python sub-process is stopping. Which may be the case if the default was python 3 - but should be fine with 2.7. Can you try running the file directly ?
/usr/lib/node_modules/node-red/nodes/core/hardware/nrgpio.py ver
should give you the 0.6.3

Only other thing I can think of is that either some other nodes are interfering ? or that you are using pins that may also be allocated to some other purpose (eg via raspi-config )

#15

Also it might be worth stopping node red, renaming your flows file to keep it safe, and restart node-red, which should give you a new empty flow. Then add just the gpio and a debug node and see what happens then.

#16

pi@PiCam:~ $ /usr/lib/node_modules/node-red/nodes/core/hardware/nrgpio.py ver
0.6.3

I do have a picamera module running on this board, but I tested it initially before I really knew about node-red with a simple python script:

pi@PiCam:~ $ cat test_PIR_cam.py
from gpiozero import MotionSensor
from picamera import PiCamera

camera = PiCamera()
pir = MotionSensor(4)
while True:
pir.wait_for_motion()
camera.start_preview()
pir.wait_for_no_motion()
camera.stop_preview()

This is why its wired to pin 7 (GPIO 4)

#17

I cleared everything out, restarted node-red and made this flow:

[
{
"id": "ca2f6aa3.4cab88",
"type": "tab",
"label": "Flow 1",
"disabled": false,
"info": ""
},
{
"id": "6e9ae6d2.603798",
"type": "rpi-gpio in",
"z": "ca2f6aa3.4cab88",
"name": "",
"pin": "7",
"intype": "tri",
"debounce": "25",
"read": true,
"x": 220,
"y": 220,
"wires": [
[
"667f7575.b468bc"
]
]
},
{
"id": "667f7575.b468bc",
"type": "debug",
"z": "ca2f6aa3.4cab88",
"name": "",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "true",
"x": 440,
"y": 180,
"wires": []
},
{
"id": "7f085591.f0e60c",
"type": "catch",
"z": "ca2f6aa3.4cab88",
"name": "",
"scope": null,
"x": 240,
"y": 160,
"wires": [
[
"667f7575.b468bc"
]
]
}
]

It appears to work. I've no idea what is going on here :frowning:

#18

If you put your original flow back and it fails again then something in that flow is interacting with the GPIO node. I see you used to have node-red-contrib-camerapi installed and node red seems confused about it. You don't get an 'unused config nodes' message on deploying do you?

#19

No unused config nodes messages. The node-red-contrib-camerapi node is not used, and shows an update available in manage pallet after I ran the upgrade script.

I'll have to track down what is interfering, Another flow starts a python process and later sends it SIGINT, perhaps this is not being done correctly and is also killing the python-gpio as well. This well be my next line of attack, although the PIR is not essential for the project now, I thought it would be simple to get it working just in case I wanted it later. Turned out to be quite a detour, but I've learned some things along the way.

Thanks everyone for all for the help.

#20

If the other flow is using the gpio then that might be the problem.