PiGPIOd Freezing or Stops Responding?

General
1

I have discovered this a few times now, usually when I am in the middle of flow design/development, one or more of the PiGPIOd input or output nodes in a given flow, never respond to in bound messages, or never generate out bound messages as applicable. I have also seen it just happen out of the blue on an existing, established flow, that usually runs 7x24. The same flow runs on several of Pi devices, but the problem when it rarely happens is not specific to a given Pi device, or NR version. I have seen it on 1.0.6, 1.1.0 and now on 1.1.2.

I tried stopping and starting the PiGPIOd service, but the nodes remain in limbo. I have to restart NR to get them to respond. Has anyone else seem this behavior? If not I may have to report the issue to the author if not already documented. I want to bounce to 1.1.3 before I do however.

2

Issue persists under NR 1.1.3. And, I have narrowed down the problem to GPIO input only. I believe I might be demanding too much from the daemon? I have 3 GPIO inputs running in parallel, any of the 3 at anytime can be triggered. When the issue occurs it usually starts where 1 of the 3 inputs stops providing messages, then shortly after that either or both of the remaining inputs freeze or seem to stop.

Any configured output pins under pigpiod continue to work. Stopping and starting the pigpiod service does not resolve the issue. Only stopping and restarting NR service seems to clear the issue. The NR log reports nothing at all unfortunately. Since other flows continue to work, even the flow expecting input, continues to work, but has nothing to process once the input sources stop.

3

I can try and replicate this - can you post a test flow that shows the problem?

What type of Pi is it running on?

4

Yup... Creating a flow that is easier to import, and exposes the issue. Testing on Pi 3 Model B, but I don't see this as being Pi device model specific.

5

I was thinking it could be a memory leak so it could happen faster on a smaller memory Pi

6

Of course, the issue that was consistent all day yesterday, so far this morning, refuses to exhibit! Oh for love of Murphy! Still testing. Good idea, I think I have a old model 1 I can use to try that. But when it was happening it happened quick, maybe 10 or 20 total inputs. Would be surprised if that would be a memory leak so fast.

7

Ok, it just happened again. Here is the flow I used to generate the issue...

[{"id":"702810e5.ed0d38","type":"pi-gpiod in","z":"2eeabf3d.ac7848","name":"Board 11 GPIO 17 Wire Grey","host":"localhost","port":8888,"pin":"17","intype":"PUD_OFF","debounce":"100","read":false,"x":140,"y":160,"wires":[["94df63dd.4654c8"]]},{"id":"5b43e1a5.7b057","type":"debug","z":"2eeabf3d.ac7848","name":"Message","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":900,"y":220,"wires":[]},{"id":"85846af.0308698","type":"pi-gpiod in","z":"2eeabf3d.ac7848","name":"Board 15 GPIO 22 Wire Purple","host":"localhost","port":8888,"pin":"22","intype":"PUD_OFF","debounce":"100","read":false,"x":150,"y":220,"wires":[["39b8d69a.9e39ca"]]},{"id":"94df63dd.4654c8","type":"change","z":"2eeabf3d.ac7848","name":"Grey","rules":[{"t":"set","p":"wire","pt":"msg","to":"grey","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":590,"y":180,"wires":[["433ecbda.4cf00c"]]},{"id":"2e863ecb.06837a","type":"change","z":"2eeabf3d.ac7848","name":"Blue","rules":[{"t":"set","p":"wire","pt":"msg","to":"blue","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":590,"y":260,"wires":[["433ecbda.4cf00c"]]},{"id":"39b8d69a.9e39ca","type":"change","z":"2eeabf3d.ac7848","name":"Purple","rules":[{"t":"set","p":"wire","pt":"msg","to":"purple","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":590,"y":220,"wires":[["433ecbda.4cf00c"]]},{"id":"433ecbda.4cf00c","type":"function","z":"2eeabf3d.ac7848","name":"State","func":"/* _________________\n       B           P|\n                    |\n                    |\n                    |\n                    |\n                   G|\n                    |\n*/\n\nconst ZERO = 0,\n      ONE = 1,\n      CLOSE = ZERO,\n      OPEN = 5;\n\nconst theState = Boolean(msg.payload),\n      theTime = new Date().getTime();\n\nvar theWire=flow.get(msg.wire) || { state: true, index: ZERO, time: ZERO };\nvar theDirection=flow.get('direction') || ONE;\n\n//\ntheWire.state = theState;\ntheWire.time = theTime;\n\nlet theMessage='?';\n\nif (theDirection) {\n    theMessage = 'Open';\n    \n    if (theWire.index > OPEN)\n        theDirection = -ONE;\n} else {\n    theMessage = 'Close';\n\n    if (theWire.index < CLOSE)\n        theDirection = ONE;\n}\n\ntheWire.index += theDirection;\n\nnode.warn(`${theMessage}, Direction ${theDirection}, ` +\n    `Wire ${msg.wire}, Index ${theWire.index}, State ${theWire.state}, Time ${theWire.time}`);\n\n// Garage Open/Close Button Will Toggle Direction As Well\n\nflow.set(msg.wire, theWire);\nflow.set('direction', theDirection);\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":750,"y":220,"wires":[["5b43e1a5.7b057"]]},{"id":"7b9b2967.5d12e","type":"pi-gpiod in","z":"2eeabf3d.ac7848","name":"Board 13 GPIO 27 Wire Blue","host":"localhost","port":8888,"pin":"27","intype":"PUD_OFF","debounce":"100","read":false,"x":140,"y":280,"wires":[["2e863ecb.06837a"]]},{"id":"f4644fad.b2f4e","type":"inject","z":"2eeabf3d.ac7848","name":"Automatic","props":[{"p":"payload"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":110,"y":340,"wires":[["1d64a115.da77df"]]},{"id":"1d64a115.da77df","type":"change","z":"2eeabf3d.ac7848","name":"Reset","rules":[{"t":"delete","p":"direction","pt":"flow"},{"t":"delete","p":"blue","pt":"flow"},{"t":"delete","p":"purple","pt":"flow"},{"t":"delete","p":"grey","pt":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":270,"y":340,"wires":[[]]}]

You will need something to generate the GPIO inputs. I have been using three(3) of the following breakout boards on the Pi3 as noted above...
image

8

testing now

Luckily the robot that i have to hand uses IR sensors on 11 and 15 so handy for the testing :slight_smile:
13 isn't connected to a sensor but I'll just leave the flow alone for the moment before changing pin to something else

9

Yeah, unless this issue is only happening because I have 3 sensors in parallel? But that would be a surprise!

Just a footnote, it has happened 3 more times. I checked freemem, there is definitely available memory, but I did not check the node specific resources. Since NR never crashes, never reports any errors, this is odd.

10

If I have time later today, I think I will setup a python script to test the sensors, in something outside of NR. Given PiGPIOd is part of this solution, there maybe some odd interaction issue as well. But as I noted, restarting PiGPIOd does not resolve this, and the output GPIO based flows I have running on the same Pi, never fail. It is just input based flows that fail, and NR restart seems to be the way to consistently recover from the issue. And, I did upgrade NR to latest, 1.1.3. I can also move this to a Pi 4 if needed. Oh, PiGPIOd is version 77... I think that is the latest?

11

Came back to it after family time and still working fine

image

Will leave overnight and see what happens

12

I think I noticed something... I was editing a functional node. And after the deployment of the changes, the PiGPIO input nodes were locked up, stuck. They never seemed to activate or reset. Absolutely zero message generations from attempted input via the sensors. They showed status OK, but not so. I restated NR, and they stated responding. This might be a clue.

I even created a new flow from scratch and have been editing the functional node, and it seems each time I do a deployment of changes to the functional node, is when the issue sometimes occurs.

13

Yup, it seems to be random, but it definitely happens after a deployment of changes, when it happens. If I edit anything in the flow where the GPIO input nodes are, and then do a deployment, the GPIO input nodes either work, or appear frozen, non-responsive. To clear the issue, have to restart NR.

14

What deploy mode are you using? Full, modified or flow?

15

Mine was OK overnight and I've tried editing the function node and re-deploying about a dozen times just now and still working fine

Was originally doing full-deploy but switched to modified nodes only and still fine

16

I have been using full consistently, even though that is overkill given I am only actively editing a single flow. @cymplecy, yup. My testing is consistent to yours, if the issue does not happen, the inputs work for hours (or as long as I have tested). But if the issue does occur, the only resolution I have found so far, is stop/start of NR service.

I am moving the testing to multiple devices, I want to rule out or in if this is device specific, or something I am creating in some way with my core image. This maybe, seems likely,, device specific or OS instance specific. I am leaning in that direction given what we have tested so far.

Will keep everyone posted as I continue testing. Is there anyway to increase the detail of the log? Or logging? Like a verbose mode or something? The default logging is not showing anything when the issue occurs.

17

Just to say mine is still running fine

18

Yeah, this has to be something with the Pi image or the specific Pi then. I am going to try a clean image and install of NR (again).

19

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