Filter msg.payload to get just one debug message

[Kayle]

Hi,

I am reading gpio17 on my Raspberry Pi to trigger a read from a pcf8574. There is a debug node on the output on the pcf8574 node which is displaying 2 messages when gpio17 get HIGH.

msg.payload: boolean = true
gpio-in#17: msg.payload: boolean = true

I want to avoid the second message, but I don't know how. Is there somebody who can give me a hint?

Thanks in advance
Kay

[Colin]

First connect the debug node to the output of GPIO node, to see what is coming from that.
Also tell us what node type the GPIO node is. What node did you install to get that? It is not the usual rpi-gpio node from node-red-node-pi-gpio.

[Kayle]

Thanks for your fast reply, Colin. I changed the usual node to an alternative node just to see if I will get there also two debug messages. I switched back to the usual rpi-gpio node with the same result.

I've expected, like the inject node do, that the node just triggers the following node without passing through the message.

BR
Kay

[jbudd]

How are you triggering the GPIO pin?

The GPIO-in node, presumably the other one you were using too, fires when the GPIO status changes.
A physical momentary switch will transition from 0 to 1 and back again as it is pressed and released.

You can use a switch node to pass only the msg where payload == 1.

[Kayle]

The trigger comes from an Interrupt on the PCF8574. As soon as I set a high signal on an input on the pcf8574, the interrupt pin on the pcf8574 goes high and this signal is connected to the GPIO17. When the GPIO17 is high, the pcf8574 will be read and the interrupt signal goes low. It is the same like a momentary switch. Even if I use the switch node, the message gets passed through and I get the two messages on the output after the pcf8574 node

[Colin]

Show us how you have configured the switch node. First make sure that you have told it to check for Number 1 not String 1.

[Kayle]

This is my configuration of the switch node:

This is the result. It is the same as without switch node:

[jbudd]

But why don't you compare msg.payload (true/false) with Boolean true/false instead of a number?

I know there are many languages where 0 == true and 1 == false, don't know about Node-red.

[Kayle]

I am not sure, if there is a misunderstanding. When I use the input of the Raspberry Pi GPIO node to trigger the read of E1 on the PCF8574, the debug node message consists of 2 Messages. One message from the gpio node and one message from the PCF8574 node.

If I replace the Raspberry Pi GPIO node with an inject node, I get just one message in the debug node of the PCF8574 node. And that is what I need also for the Raspberry Pi GPIO node. So it is not about triggering with true/false or 1/0, it is just avoiding that the Raspberry Pi GPIO node message passes through the PCF8574 node to the debug node.

[Colin]

Add another debug node so we can see the output of the GPIO as well as the other two. Then, with them all enabled, see what is in the debug pane.

[Kayle]

Here is the result:

As you can see, the debug message from the gpio node is looped through the other nodes. What I did not understand is the "gpio/17 : msg.payload : number (boolean)". I thought I could just "filter" the gpio/17 after the pcf8574 node, but I am not able to do that because I just can filter after the "msg.xxxxx" part but not the gpio/17 before.

When I use an inject Node with the payload 1/0 or true/false instead of the gpio node, there is no seperate debug message which is looped through. I've tested this several times.

[Kayle]

Ok, the part with the gpio/17 before the msg.payload is the msg.topic. I have to investigate further.

[ralphwetzel]

@Kayle

gpio/17 before the msg.payload is the msg.topic

If you change the output format of the debug node to complete msg object you can easily spot the full data that's in the flow...

[zenofmud]

@Kayle It's really helpful, when you have an issue with a node, to specified the full name of the node and display the way you have configured it. It is also a good idea to check out the node's GitHub issues page to see it you are running into a known issue.

[Colin]

@Kayle

there is no seperate debug message which is looped through

It isn't a separate message which is looped through. The gpio/17 in the debug message is just that the input_E1 node is passing through the topic from the gpio node. As others have said, it would be useful to tell us what node type that is, node-red-contrib-something possibly, and how you have configured it. The issue is, why does that node send two messages when you pass in only one?

As well as telling us about that node, add an inject node to your flow, injecting the number 1. Feed that into a debug node and into the input_E1 node and show us what you then see.

[jbudd]

Judging by the word "PCF8574" and the node icon, I take it that @Kayle is using https://flows.nodered.org/node/@pizzaprogram/mcp-pcf-aio

The node seems to regularly poll an MCP23017 device on I2C.

From the node help :

Use the Input point of this node to trigger a full read of all Pins. The payload must be 1 or true to do that.

The resulting message will be an array with these values: msg.payload, msg.immediateReadSuccess, msg.readingTimeLengthMs, msg.AllStatesRaw, msg.AllBinary

(This kind of immediate forced read is not always successfull, so make sure: msg.immediateReadSuccess == true, or repeat the readout.)

Are you perhaps seeing an output from the polling function followed immediately by the triggered read?
I don't think that can be right unless GPIO 17/pin 11 is somehow connected to the I2C bus.

Can you filter out the extra message after the PCF node by testing msg.immediateReadSuccess == true ?