Watch node firing multiple times (> 2)

General
1

I'm using the standard node-red: watch node and I'm having trouble getting it to fire consistently, or allow me to filter the fires to continue the workflow one time.

It is the entry point for an AI inference model where a camera will send the image to the file system, node red then executes the .py and returns the inference result to be sent back to an HMI.

It's all working, except that it runs the workflow up to 4 times. (this kills the processor)

This is on Windows 10IOT, latest version of everything (started fresh yesterday). It seemed to work ok on Linux over WinSCP, but when I drag a file in to simulate the camera transfer it will fire multiple times. I filtered the 0 out, that was the easy one.

Some initial testing - the .png fires twice (same payload), a .jpg will fire four times also identical payloads.

From a single transfer/execution.

D:\\ai\\images : msg : Object
{ payload: "D:\ai\images\37gd2h.jpg", topic: "D:\\ai\\images", file: "37gd2h.jpg", filename: "D:\ai\images\37gd2h.jpg", size: 95320 … }
10/16/2019, 8:29:32 AMnode: 6a69fd99.a24024
D:\\ai\\images : msg : Object
{ payload: "D:\ai\images\37gd2h.jpg", topic: "D:\\ai\\images", file: "37gd2h.jpg", filename: "D:\ai\images\37gd2h.jpg", size: 95320 … }
10/16/2019, 8:29:32 AMnode: 6a69fd99.a24024
D:\\ai\\images : msg : Object
{ payload: "D:\ai\images\37gd2h.jpg", topic: "D:\\ai\\images", file: "37gd2h.jpg", filename: "D:\ai\images\37gd2h.jpg", size: 95320 … }
10/16/2019, 8:29:32 AMnode: 6a69fd99.a24024
D:\\ai\\images : msg : Object
{ payload: "D:\ai\images\37gd2h.jpg", topic: "D:\\ai\\images", file: "37gd2h.jpg", filename: "D:\ai\images\37gd2h.jpg", size: 95320 … }

Should I be using a different node here? Is there an updated one? Not sure what to do here.

2

Maybe use an RBE node to filter out duplicates?
Or if it's because the writes are slow and you need to ensure it's finished then maybe a trigger node set to send nothing at first, some small timeout - but extend the timeout if another message arrives during that timeout, and then send original payload.

3

You are falling foul of the problem with watches. They trigger whenever the file is updated and that isn't when you think it is.

You will need to filter out the multiple changes. you should also add a delay before you trigger your flow to give the final update time to finish.

4

That is a common problem with the watch node. The watch events are generated by the operating system and if the write itself takes some time then the OS sees the file changing multiple times and the watch node is triggered multiple times. Whenever I use a watch node I follow it with a Trigger node as suggested by @dceejay set to do nothing initally but send the message on after a few seconds to make sure the write is complete.
I think the suggestion to use an RBE may not be reliable as it will pass the initial message on immediately and you may find yourself reading the file before it has finished writing it.

5

:smiley: I didn't suggest that. Just to filter out multiples - how is left as an exercise for the reader. You could use the first change as the trigger as long as you can predict the time it takes to finish the changes but I agree that it isn't generally sensible.

6

Correct, somebody else did. Your post had not arrived here when I sent mine, even though the timeline now shows yours several minutest before mine. I have noticed that situation before.

1 Like
7

Sorry, that'll be the time machine, I keep forgetting to turn it off.

8

Welp.

I was hoping I did something silly, didn't RTFM or something in that orbit. I started to look at ways to stack the messages and then fire after a settling timer, but wanted to make sure I didn't miss something obvious before journeying out in the weeds.

Looks like I'll set my solution GPS for the weeds and see what happens.

Thanks all.

Edit: Simple enough, added a 1sec trigger that resets if it gets a new message. All testing points to that being acceptable but I have some space to open the timer for longer if I must. I've accepted @dceejay's answer.

9

As has been suggested, all you need is a Trigger node.
Building this into the Watch node, as an option, would be a useful enhancement if someone felt strongly enough about it.