So, I am a little confused. I guess i have assumed that "inline" means the node would lose the button on the right and instead have an output port so that it becomes and inline node (perfect for avoiding the cloning of large message data)?
PS: It is not ideal for docs to be an external link. air gapped installations would have no information on how to use your node. There is a documentation guide that can help you structure docs here: Node help style guide : Node-RED you can even write them in markdown Since NR 2.1.0 (which greatly simplifies the task)
Would you consider changing the node colour to the same green as the debug node (or similar)?
I instinctively see (and ignore) debug nodes (much like comments in code) when reading the flows. Visually, I know without thinking this is not a logic or functional type node. conversely, when looking for debug nodes - my eyes find them quickly (like comments in code)
Absolutely feel free to ignore this request BTW. I will 100% understand if you would prefer not to and will in no way be miffed
node color
will be changed, it was green but then I thought people will mistake it for debug component.
inline mode
Inline mode was initially though out to be designed in a way you could put it in the middle of the flow and log messages down the stream, but it was a bit confusing. Also with introduction of wired mode you can already log messages of all connected nodes.
What would be the use case to put logIO in the middle of the flow and log messages of downstream nodes?
error
With what user are you running node-red? Bottom line is user running node-red doesn't seem to have write permissions to write to that file. That I can't fix, you'll have to look into file/folder permissions on your system.
I 100% agree though that this should not hang the node-red instance - I'm looking into it and it will take me some time to modify 3rd party dependencies as it seems I can't catch the error from asyc process without node-red hanging.
Not confusing at all. Mind you, coupled with "wired" mode it does get confusing.
"Wired" suggests there is another mode where wires are not needed (I actually tried that)
In my head, the two modes of operation would be "inline" and "standard" or "in-out" and "in-button" or use a tooltip or a dynamic label.
PS: out of curiosity, how does inline and wired modes differ in their current form? Other than changing the available setup options and the nodes status text, i see no difference TBH!
When a node has multiple output wires attached, the msg is cloned for each. If this is large data (like an image, or audio buffer etc), then an inline node can avoid this overhead. This can also have subtle side effects. for example, you may be depending on the property being a reference to an object in the heap but if the msg is cloned (due to output branching), the downstream results are affected.
PS: I assume you meant "upstream" (i.e. nodes to the left of the log node)? The interesting use case is that I can log a point in time message (as it passes through) without any cloning and without any mutation from what happens to it downstream.
I did preface that with "I fully appreciate this could be down to settings I entered" - had I not entered ../ in the directory I would never have noticed the issue. I have since modified the dir to a path with permission to write (and it works)
I fully appreciate you did so we can avoid such errors in the future. You as an experienced node-red user knew how to solve it immediately on boot loop, others might had more issues.
Inline mode behaves as debug node, logs only IN messages that come directly into the node.
Wired mode logs IN (or IN/OUT) messages of all nodes that are in any way connected to logIO node upstream even if branched out - so basically whole connected scope of nodes.
I mean down as that's how initially inline mode worked, it logged messages coming into the node and also all messages downstream (to the right).
Perhaps I should rename inline to normal mode, and introduce new inline mode that does what we're discussing (pass through msg + logging down/up stream) - I have to rethink a little.
Bug where writing to file without sufficient permissions that resulted in node-red boot loop should be fixed. You also get a warning in debugger, console panel and all nodes that are using affected configuration are visually marked with error status.
For easier representation of nodes that are being logged by current logIO, version 1.1.5 adds highlights of all nodes monitored by logIO when editor is open.
In version 1.1.7 you can save yourself 2 clicks if you want to use logIO like internal debug node.
Previously when creating new logIO node you had to open the Edit panel and define the logger, even if you only wanted to debug to NR debug panel.
With new version, you can start using the logIO right away even if custom logger is not defined. In this case logIO will behave as internal debug node -> log to debugger panel.
If logIO node has no custom logger defined, this will be denoted with a little square next to the name.
