Question: "Reading" Raspberry Pi GPIO rather than using as "input"

[Ty Marbut]

It seems like a rather basic capability, so maybe I'm missing something: Is there a way (a node?) to "read" from a Raspberry Pi GPIO pin as a passthrough node like reading from a file, rather than using it as an input and generating a new message, like incoming MQTT or inject?  The less-than-graceful way to do this would seem to have every input from a GPIO pin written to a file, and then use a trigger node in a separate flow to read that file and pass its contents.

My application:

Running Node-RED v0.12.1, Node.js v0.10.29.  Reading 24vAC thermostat inputs (5x) through a circuit that steps the voltage down and rectifies it.  The problem is that there's a significant amount of capacitance in the whole 24v system of relays, valves, etc., and it causes the GPIO input readings to fluctuate a lot for about 1 second when the thermostats turn on and off.  For example, I might 3 messages of "0" followed by a "1" when the system turns on (should go from 0 to 1); or I'll get strange multiple-digit numbers like "111" and "0000" and "011" and lots of "00".  No matter what happens, the last message in a series of 1-10 messages does seem to always be the right value.  So, if I could read from that input once every 20 seconds or so, the error rate would drop considerably.  And I'd like to avoid something as unelegant as writing to a file several times a second, a couple dozen times per day.

The whole thing with the multiple, identical GPIO messages is another issue altogether, but for now I could get around it by just reading every so often.

Thanks very much for any ideas.

[Dave C-J]

Hi

the RBE (Report by exception) node would help to filter out duplicates. 

Other than that - a function to write (set) the gpio value to a global context - and then read (get) from that in another function. http://nodered.org/docs/writing-functions.html

[Greg EVA]

@Ty,

I would agree with Dave's suggestion.  The RBE node is pretty great.  As the whole system is event based, new messages need to be fired when things happen.  This isn't like the automation world where you scan a snapshot of I/O statuses updated at each scan.  However using Dave's suggestion you can create this using global context variables (and objects).

I am in fact doing a combination of all approaches, and use the Later.js node to periodically fire a new event/message which I then calculated stuff and update other stuff; basically storing data every 5 minutes.  'Later' is pretty great.

A couple other things that I do, coupled with my periodic triggering, are watching data changes, calculating a period running average, a min and max value, as well as using the Smooth node (I think that's what it's called) to filter out data bounce over X number of records (my records flow in at a steady rate however).

Cheers,

Greg

[Ty Marbut]

Hi Greg, and Dave,

Well, I think you guys are definitely onto something with the RBE node.  Also, when I get double/more digits back from the GPIO (which still is very weird), I think one way to clean them up is to parse off the last number and use that.  I have the idea that the last number in the multi-digit number is the most recent actual reading (if it isn't entirely random).

For my future reference for other flows, however, I take it from your answers that no, there isn't a way to "read" a GPIO pin, other than storing its value (global variable, file, etc.).

Thanks to both for your suggestions!  Greg, are you implying that you are also reading from 24vAC, or are you just saying you do those things in your flows generally?

-Ty

 

[Greg EVA]

@Ty - no, I am not currently reading from 24VAC... but that part really doesn't have anything to do with Node-RED (as it is instrumentation and sensor level).  What I was mainly referring to is that there are two conflicting approaches here: scheduled and unscheduled, or polled and unsollicited, or event driven and periodic, etc.

Node-RED is event driven (and also Node.js, Java, etc) - it is a bit of a change in thinking but is pretty powerful and fast as you can have things firing off right when you want them to, as opposed to once you've been able to detect the condition, and fire your logic.  Just as an example; your GPIO connected to Node-RED with an RBE node pushing the data to an MQTT broker.  The data would be published right when it changes (not in 20 seconds after another scan), and there are no wasted publishes in between.

[Julian Knight]

The main downside of event driven IO being that analogue readings can generate a very large data stream very quickly which can flood your analysis. That's where RBE comes in as well, reducing the flood to something manageable.

You can also get a flood on a digital pin when the attached sensor is not stable. If you are getting very large/random quantities of responses from a digital pin, you probably need to up the resistance on the pin to help it stabilise.

[Ty Marbut]

That's something that confused me about the RPi GPIO nodes.  I totally understand the nature of it being event-driven, but I had assumed that there was a certain RBE functionality built into the RPi GPIO nodes, and didn't expect to get a series of the same inputs, or multi-digit inputs.

I added the RBE as suggested, and also am using the last digit of multi-digit messages from the GPIO.  Still something is wrong, but I haven't debugged it enough yet to ask for any help with it, so that's my next task for today.  Meanwhile, does anyone know what the root cause is of these multi-digit readings?  Is there a certain GPIO frequency (either software refresh frequency or hardware sampling frequency/window) that would cause multi-digit GPIO responses?

Meanwhile, thanks to Greg. Yeah, I understand that the 24vAC reading is really hardware related, but the rub is when I get these multi-digit GPIO messages inside Node-RED.  So, I got some new, professionally-engineered 24vAC-5vDC converters in the mail yesterday, so I think I'll try those first and see whether they give a more consistent output to the Pi, and hence to Node-RED.

[Greg EVA]

@Ty - I think it's a good idea to try to get it back to 5VDC for the Pi simply as most people are working with this so obviously means more support, stability, etc.  I tend to often find myself coming against things that it appears no one (or few) people have done it that way... and it is frustrating to spend days (or more) only to find out that there is effectively something wrong.

Not that I've ever played with RPi GPIO, but from what I've heard there are some standard libraries, source code, tools, etc. for working with it in either Python or even with some shell scripts.  If I were you, I would try getting a bunch of readings using these methods to see if you are getting the same strange values (and rule out Node-RED in the process).  You may also uncover clues along the way to set you on the right path.

Cheers,

Greg

[Julian Knight]

I think that is good advice Greg. With one exception. I think you want 3.3v on the Pi GPIO not 5v?

[Dave C-J]

Hi, the GPIO nodes talk to the python API RPi.GPIO which is installed by default.

The calling program is nrgpio.py  usually in /usr/lib/node_modules/node-red/nodes/core/hardware (but may not be depending on how you installed Node-RED in the first place)

Within that lines 96 and following handle the digital in (for example).  There we set an interrupt looking for any edge with a bouncetime of 20mS (set on line 23)m then read the input and output it to Node-RED.

Net is you may want to try adjusting that bouncetime - too long and you limit the number of events you can see per second... (ie you may miss the second part of 0->1->0) - too small and it may not have settled. This is why you sometimes see 000 or 111 etc - hopefully the last value is "correct"  

I'm certainly open to changing that default value if we can agree on a better one - and indeed pull requests are welcome for better ways not to miss an edge that "always" report the correct value :-)

[Dean Sellers]

There is always the possibility that either the hardware is faulty, perhaps poorly connected. Also possible is a simple hardware debounce.

Could you provide some details about the circuit you are using to connect the IO?

[Ty Marbut]

Hi @Dave - very interesting.  That helps a lot.  I know I'm introducing the problem due to the capacitance of the circuit that rectifies/steps the voltage down, but for the first time you've given me a way to think of the on/off timing quantitatively.  Now, theoretically, I could vary the capacitance on the 5v side of the circuit to work with the 20ms timing.  Thanks again.

Also, to all, sorry I didn't mention the second step from 5v to ~3v - I figured that would be a given.  But for anyone out there worried about the Pi that's sitting there smoldering in my basement, I'm feeding the GPIO pins around 3v.

Good idea from @Greg to use other methods to get GPIO input.  I think, though, that Dave has confirmed that this is to be expected when a circuit is quickly fluctuating in voltage.  And that's totally what's happening - this is a system with multiple relays (some of which I can hear click on and off more than once as the thermostats click on/off), multiple 24vAC power sources, ancient zone valves, interconnected pumps, etc.  There's bound to be some weird capacitance/resistance circuits in there somewhere causing a fluttering voltage, not to mention the capacitors on either side of the rectification and voltage step-down.

One other test, which has little to do with the Pi or Node-RED, would be to hook up the same Pi with the same code to a single, otherwise unused 24vAC power source and see whether it throws weird values after rectification/transformation.  If not, then it'll be all about filtering those results, rather than looking for the problem within the Pi or code itself.

Thanks again for the time answering my many questions - I'm new to the Pi and Node-RED, I absolutely love the whole concept and execution of Node-RED, and I have quite a few 24vAC controls I want to take over with Pi's in the foreseeable future.

[Ty Marbut]

@Dean - maybe my post above clarifies somewhat.  I don't have a full circuit diagram, but basically it all revolves around a 7805 voltage regulator, a diode for rectifying, and a 100uf capacitor on the 24vAC side and a 47uf capacitor on the 5v side, followed with a resistor netowrk to drop the foltage to 3.3v (and then about 12ft of wire, such that the Pi is getting about 3vDC).  I wish I had an oscilloscope or something to help me visualize the voltage coming to the Pi over time, but unfortunately, I have only a regular multimeter which is giving that ~3v reading at the Pi.

[Dave C-J]

I'll have a look at making the debounce a more configurable option (iE exposing it in the edit config - rather than hiding it in the .py file)... May take a few days to test it out. but shouldn't be too hard.

[Ty Marbut]

Wow - well that's really cool.  Thanks for at least taking a look at it.

Also, did I say that I really love Node-RED and thank you for working on it?  After I totally stumbled across it in my brand new Raspbian, it allowed me to take control of the Pi and do things I didn't think were remotely possible for me without years of coding background.  In about 2 weeks, I went from only being able to use my Pi as a graphical desktop computer (and having virtually no coding capability), to measuring, logging, analyzing, displaying, publishing, and forecasting complex data, and taking control of a complicated home heating system to significantly improve its function and efficiency (despite the relatively minor bug in my DIY hardware that spawned this thread).  The next week, I started controlling two of my ham radios to provide a message passing functionality like MQTT between two Pi's a dozen miles apart (or with one of the radios, potentially for thousands of miles over HF bands).  Next stop is data logging/analysis/serving and eventually control of a small agricultural and 2-home water system with 4 wells, 3 reservoirs, external water supply, and 4 separate pumping stations.  Again, I'd have been nowhere on any of this were it not for stumbling upon Node-RED and the ability it gave me to actually use this functionality of my little Pi's.

Anyway, I will update here when I switch to the professionally engineered 24vAC-5vDC converters and maybe for my particular purpose, that will be totally sufficient.

Thanks for the help.

[Dave C-J]

Excellent ! Exactly the sort of multiple use-cases we hoped people would use it for... :-) Glad you enjoy it, and thanks for all the feedback.

[Greg EVA]

@Ty - It's perhaps overkill for your application, but as you mentioned wanting to control many 24VAC loads, have you considered looking at a remote I/O block of some sort which you can interface with the Pi/Node-RED?  This way all your AC stuff would remain on the designed for AC I/O, and you could connect to and control it from the Pi - and you wouldn't have all these conversion steps in there.  I am thinking about something like the Wago 750 system... here is a link to one input module... you'd need outputs obviously, a network interface (even just serial, or Modbus-RTU or TCP/IP), and a terminator slice.

http://www.wago.us/search/index.jsp?_ts=1421664247535&action=morearticledownloads&q=750-415

Also.... really cool progress that you've made in a short time as well as your future plans!

@Dave - I think exposing the debounce configuration is a good one.  From my experience, when you really get into it, various applications and needs are different so it's not really possible to choose an appropriate debounce that will work everywhere.

[Dave C-J]

While digging around a bit more deeply I have found (what I think is) a slightly odd behaviour of the edge interrupts debounce. So I've contacted the library author to get a clarification. Net result is it should get a whole lot better :-)