Can the file in node read from stdin?

General
1

I assume not as windows systems don't really have stdin or stdout. But I figure its worth asking.
Edit: Forgot to mention I'm using node-red on Linux for this particular use case.

If file in node could read from stdin I could avoid creating an intermediate temporary file.

2

Which stdin ? Each process has its own stdin and stdout etc. Using a temporary file is the simplest way to do what you want.

3

What is it you're trying to achieve? There may be other options. E.g. if the stdin you speak of is generated by a simple python application, you may be able to re do it in node-red.
If it's a complex app, but you have access to SRC, you might be able to add MQTT or other method of communication.

4

Basically its a bash script run from from a node-red exec node. There is no upside to re-writing it in anything else as it has been very reliable running for about a year and a half.

I'm just looking to remove the temporary file to perhaps save some wear on the SD card. I think the on-going logging of node-red and Raspbian are likely larger issues, but this I have control over.

Edit:
I just discovered /dev/shm. Looks like writing to it reading from it will be the simplest solution.

5

The upside to rewrite is the visual element, dashboard monitoring and control, debug output, ability to feed results on the fly to (for example MQTT), email on error/success.

Some options I can think of at this time in the morning...

  • Rewrite (if not too big)
  • Save results to a ramdisk
  • Fire off MQTT from script (example)
6

I am missing something in my understanding here. If a script that writes to stdout is run via an exec node then I would expect the stream to appear on the exec node output.

7

Also confused. The exec node provides the stdout from whatever app you run. The is also node-red-node-daemon for long running tasks that provides stdin and stdout to a task.

8

Maybe I'm missing something, but the issue is moot, as I can write the file to /dev/shm and read it with /dev/shm/xxx as the filename, but the file input node seems to need a file name. Are you saying if I hook the exec #1 output to the file in node without a filename it should also work?

9

Probably not. We were just wondering why use a file at all, when the exec node will supply anything your script normally sends to console , to the output of the node anyway.

10

I've got to process the output of the script line by line. The script scans for Bluetooth devices and returns what has been found, but most of what it finds is not what I'm looking for and the data returned is device dependent. The might be "better" ways to do it but this works great (well over a year of 24/7/365) but I had an SD card corrupt so I'm looking for ways to possibly save "wear and tear" on it.

I need to spend some time to research how to turn off all Raspbian and node-red logging which likely writes a lot more, as my script runs like 4 times per minute and outputs from 0 to ~300 bytes.

11

This is my last attempt to sway you :slight_smile:

As you're hell bent on not redoing this in pure node-red (which is a shame as not only would you lean heaps but others could gain from it too) I'll suggest the following halfway house instead...

Add MQTT to your python program and transmit your data in JSON format (example) No file, all realtime. You could even increase scanning time to as fast as it'll go.

If you format your messages with a topic and a JSON payload, using a switch node you can very easily and cleanly separate the wheat from the chaff and your payload would become a js object (due to using JSON) so accessing properties is simple dot notation.

Let us know how you end up solving this either way. And Also would be nice if you document how you end up disabling the logging and other file writes. :+1:

OS, if you decide to go this way but have questions, we can help.

Good luck.

12

This is what the daemon node is meant for. Use it to call your long running scan and the node will output lines as they get reported. You can then filter them as appropriate.

13

As I said, I've already "solved" it by using /dev/shm. I use MQTT pretty much everywhere, but no python involved in this task.

Reliability has outstanding running 24/7/365 with automatic recovery from power outages and wifi disruptions until the SD card corruption happened. I've an "identical" system out in the garage to which I've also changed to use /dev/shm. Its a few months newer, so if its SD card gets corrupted in a few months disapling all system log file writing will be a priority, Now its not, I'd assume the Raspbian developers know about SD cards not holding up all that well to lots of write activity and did what they could to address it.

A quick bit of Google suggests:

sudo systemctl disable rsyslog
...

For node-red , edit the setings file:

...
// Configure the logging output
logging: {
// Console logging
console: {
level: "info",
metrics: false,
audit: false
}
}
...
and change level: from "info" to "off"

I haven't done it yet.

There may still be other on-going system logging processes I'm not aware of.

14

My BLE beacon code is a shell level hack to avoid writing a java program, as its the only "real support" they offer (they are totally geared to Android and iOS). I let it scan for N seconds and kill it, I don't get the output of how many beacon packets were received during the interval until its killed. Ugly but it works more than good enough.

As I si

15

Its an IOT application, my entire design philosophy is "set and forget" The only monitoring is the other set and forget piece that uses its MQTT output will send me a text message it stops getting updates -- this usually happens from WiFi issues a couple of times a month, it recovers automatically although I've a bug where sometimes I don't get the message that it has recovered when it resumes working, although usually I do,