THIS ONE HAS BEEN SOLVED – SEE “SOLUTION”.
I freely admit to being utterly stumped. Having spent the day getting node-red on the Blackberry Pi2 I’ve made this simple page… an MQTT message coming in is passed out… and also goes to GPIO 0. This works – send a 1 in the message – the LED comes on – send a 0, the LED goes off. The litttle indicator below GPIO 0 shows the 1 or the 0.
TCP in… I’m using NETIO on my phone to sent a TCP package with 1 or 0 in it. The TCP reply is necessary or NETIO won’t respond. Send a 0 via TCP – and the light goes off (if, say turned on by MQTT).
Lovely.
But – send 1 via TCP and the light flashes ever so briefly – ending up OFF – even though the little indicator on GPIO 0 says 1.
It’s as if the 1 command I’m sending from the phone is being followed by a 0.
The other strange thing about GPIO is that if you send a blank message or a space from MQTT it also turns off – it’s only supposed to be affected by 1 or 0.
SOLUTION:
Well, it turns out that any whitespace or a RETURN sent to the GPIO module – turns the output OFF – how DAFT is THAT? The solution was simple.. filter whitespace out of the incoming TCP signal.
var newMsg = { payload: msg.payload.trim() };
return newMsg;
And here it is in action…
In the picture, it’s not clear to me how the TCP in is routed to GOIO 0. Perhaps as @Ben said, the JSON would help.
You didn’t mention how you were sending packets to the TCP in. If it is with telnet, there are going to be plenty of padding and control bytes added. That is the most likely culprit.
I figured there must be something else in there that’s turning the output off immediately. I did notice that a SPACE or a RETURN turns the GPIO off – and that to me is just bad filtering in the GPIO module.
As a result of your emails Ben and JASON.. I followed a hunch and added a FUNCTION in line with the TCP code….
var newMsg = { payload: msg.payload.trim() };
return newMsg;
And VIOLA – the problem went away. I’ll update the blog accordingly.
So without seeing the actual config it is hard to say from the diagram. If you can email me the JSON for the flow I am happy yo load it in and take a look.
I am not familiar with the RasbPI GPIO node as I have never used it, but it looks like you are missing a function node to process the messages received and act on them. I would have expected to see a function node in between MQTT In and GPIO 0 and TCP In and GPIO 0. That way you can also put code in your function node to only act on messages recieved via MQTT that meet a certain format solving you blank and space problem.
Does that make sense?
Also shameless plug, but I wrote up a quick post on using Monit to keep Node-Red and Mosquitto alive and monitored on my new blog if your interested.
Shameless plugs on-subject are welcome – and as it happens – I discovered I had to do all of this as ROOT and I’ve yet to make sure the PATH to node is right on powerup – I already have Mosquitto running on Powerup – so id you have a solution to that, fire the link away by all means.
So my post here http://blog.bwhouse.net/mmonit/ talks about setting up Monit to monitor and restart Node-Red, Openhab & Mosquito. I haven’t yet written about the install process of Node-Red and creating a upstart config so that it starts up on boot.
There are however several good tutorials that cover this. I would recommend the Adafruit one for RasbPI here https://learn.adafruit.com/raspberry-pi-hosting-node-red/what-is-node-red it goes through both installation and setting up an init file to make it auto-start. I personally prefer using upstart scripts, but init will also do the job and create a PID file required for Monit monitor it.
Hi.
I’m not a NodeRED expert, but is there any way to log what is coming into those blocks? Then you could find out what you’re *really* receiving and whether it’s the transmitter or the receiver that’s at fault.
—
Mike