A flashing node for the edit screen - requeset

Core Development Feature Requests
1

When I first started with NR I was only using the EDIT screen.
That served me needs for MONTHS!

But slowly graphical representations crept in and I had to use the Dashboard.
No problems there.

So what I am talking about here/now?

Well, as I am sure most would agree:
debugging is done on the EDIT screen.
(Side note: my screen is an old 16.9 flat screen TV. Note: OLD! so resolution is 1368 x 768 - there abouts.)
I can't have the edit screen and dashboard both visible at the same time.

When I'm debugging I use debug nodes - as their names implies - but sometimes they confuse the issue.
Their recent addition that they can display text below the node and NOT output text to the right side of the screen is handy too.
Another trick I use is the trigger node to flash the dot under it when it receives a message.
Then I know the message has got to that point. That is handy tracing a message's flow/path through a flow.
You watch the trigger nodes blink at you as the message travels it's path.

But sometimes that is hard to see.

Suggestion/request:

A debug node (I'm calling it that only for the sake of giving it a name) that has a few options:
Display message text below the node; in the debug list; flash the node for a given time and colour.

What are you talking about??

I don't know if the edit screen would support changing it's colour dynamically.
But like the trigger node (well: maybe not) you could set how long it flashes and the two colours.

That way if you are debugging message flows, you could put these nodes around the flow and better watch the message propagation through the flow.

Yes: It is a big ask and probably wouldn't be used much.
But if you needed something to trace messages I think this would be invaluable.
Then when done, the nodes would simply be deleted.

2

Possibly a lot to cram into the Editor (and it is called "the editor" for a reason isn't it?) if it wouldn't be used much? After all, nothing comes for free.

Maybe a separate "monitor" window might be better? I've done this before where a custom logging function in settings.js redirects log output I'm interested in to MQTT and a monitor endpoint accepts the MQTT msgs and shows them on their own web page.

Truth is, that needs a bit of TLC to make it more friendly and easier to implement but it doesn't suffer from the slow-downs that the debug panel can.

Just an alternative thought.

3

Fair enough.

I wrongly thought the GUI switch node was a bit more active when it receives messages.
But I just saw it isn't. (be it ever or any more.)

'twas just a thought.

4

And not a bad one. I do think that there is room for a more comprehensive log available in a web page. I certainly find myself using my kludgy one often enough. But possibly as a contributed node rather than something added to core?

I'll add it to the (very long) list of ideas to get to one day. :grin:

5

Well, ok. Following on from what you (and others) have said about the log.

There is confusion - my end - on log. Is that output to a file, or is it general output that can be sent to the terminal?

Other than node.warn that sends things to the debug column (right of the screen),
Is there a way to send the output to ONE specific terminal?

I'll explain:
I get it that this may not be much better than using the debug on the right of the screen but it isolates the output to WHAT YOU WANT.
Yes, NR has (recently) allowed debug output from either ALL or current flow.
(there may be more, but for the sake of brevity.)

I am writing code and want to watch things/messages go through the flow.
Ideally (as I suggested) I put nice flashy nodes on the EDIT screen that visually show me the message's transition.

Moving on: I put debug nodes all over the place and watch them on the right.
Given there MAY be nodes on different flows (and I know that is a whole other problem) a way to get nodes (MULTIPLE/MANY) all to send their output to ONE SPECIFIC terminal?

That way I am looking at that window and ONLY the stuff of interest is showing and any other debug nodes that may suddenly pop up their message/s don't distract/confuse the situation.

6

Could junctions be made to "light up" for a period when a message passes through?

7

That is nice, but I fear you are missing a crucial part:

This node for which I am asking if a very short term use.

It is used if/when you have those weird happenings and need to ONLY THEN watch the message's path.

Once fixed the nodes would be deleted and not used in the ACTUAL flow.

Adding that to that node would be a huge imposition on it to always happen when the node I want is only for short term use.

8

It is output to a system log service. That might be a file or it could be stdout depending on how you started Node-RED. Typically, if you start NR as a service on Linux, the output goes to the systemd journal which is replicated into syslog which is saved in a file.

So the exact answer to your question is "yes" :slight_smile: Both a file and you can output to a console as well.

node.warn|error|log all output to the NR log but warn and error are also replicated to the debug panel.

You don't really get logs to ONE terminal, rather you give a command in the terminal to get the log displayed. That is, if you started NR as a system service. If you started it manually, the log will already be on the terminal you started from.

There are ways. But not easily. Really, you will need a custom log node that outputs to a custom log with a way to display those custom logs. Node-RED has custom logging but it is at the central log level and what you can split out will depend on how a node has been written as to how easy it is to know what node is outputting something. And there isn't - as far as I know - any way to know which flow tab a node was logging from. Hence the need for a custom log node.

I have demonstrated custom logging in the past using a sub-flow I think was my original one. The sub-flow either outputs to MQTT or to websockets and you need a web page to display the output.

As I said, I think that there is certainly room to have an actual node that can do that kind of thing.

I'm glad you've raised that again because it is indeed important not to overburden the Editor which, after all, is for editing, not necessarily for monitoring. (though I think that we all do do that with some flows).

A custom node could create a new side-panel or use a separate webpage (which would probably perform a lot better) and of course, could also use the status like the core debug node does. But you need something that lets objects/arrays be collapsed (like the debug panl) - or better still, something that looks like the browser console which is a fantastic display with colour, collapsed objects, timestamps, etc.

image
image917Ă—530 48.7 KB

9

Ok, progress.

Yes, I am on Ubuntu. Not win-doze.

Putting aside the Multiple flow part:

I want n nodes on this flow.
All sending their message to the SAME console/terminal (console eluded me just now).

That way I have ONE console at THAT time to watch the messages go through.
Not on another screen. (I've explained that reason earlier)

Yes, real estate is then going to be a problem. But that's a whole other thing.

I want something that shows me the messages from these specific nodes in a singular window.
Then I watch the scroll from it and can see what is going on.

It is a kind of step up from the selected nodes which is offered as is.
Just that is...... not conducive to being used if the nodes are all over the place on the flow.
This way you put the nodes where you need them and they all send their output to the ONE console.

You did say that these messages (status quo) are sent to the log file as is.
But that gets back to the other problem I mentioned:

you are trying to work out why this bit of code isn't working.
On the machine there are other tabs and they are doing their thing quite happily, and at times unknown to you at this point in time.

So looking at the log you would get all the messages you want to see, but would also be confused with any other message that crept in during that time.
This would only obfuscate things.

I have a couple of ideas brought on by what you said, but I think that is maybe making a complex situation even more complex than it needs to be. But I can't be sure.

Ok, the idea:
Maybe going down the path you just said anyway.
And given the nodes may need an env$ to be set. Not a deal breaker.

A pop up window is opened and shows the messages arriving in the nodes with node name and message.

This isn't needing to show all parts of the message. Simply a message/signal saying Node x got a message at this point in time.
The ACTUAL contents of the message is beyond the scope of this request.
This is merely a centralised point where you can see that the messages are at given points at a given point.
And: ONLY your messages. Not erroneous ones from other flows / nodes that are legitimate but not wanted.

10

I might be wrong (or mis-understand your comment) - but clicking on the headline of a debug message in the debug side panel highlights the node that sent the message... and even jumps to the flow tab where this node can be found.

11

If you are talking debug then: YES.

This is talking log file.

12

Yes, sorry, not articulating well enough. I meant that the custom log you can create in settings.js

image
image871Ă—531 23.2 KB

Logging : Node-RED (nodered.org)

But a custom logging node should, I think, be able to find out the id of the logging node and what flow it is on.

13

Would I be pushing the friendship if I asked for help with this - NOT NOW.
But at some stage in the future?
(maybe a week or month down the track?)

I'm just somewhat inundated with things just now and as much as I would like to get this in my toolbox: Just now isn't a good time.

14

We are always here :grin:

15

Well, I did feel it was better to ask than just expect it of you.

I have just now had a lot of fun with MQTT messages.

I can't believe the problem has existed for so long.
Though I suspect recent work has provoked/changed/made it happen.
But it was painful. :frowning: :cry:

16

The discussion has gone off in a different direction (logging), but I thought this function node might be of some use to you in the meanwhile.

[{"id":"5cc79293a6fbfc60","type":"function","z":"95202e92.939cf8","name":"flash 3x","func":"let timerID\nlet count = 6           // 3 flashes\nlet interval = 500      // ms\nlet sOff = {}\nlet sOn = {}\nsOn = {fill:\"red\",shape:\"dot\",text:msg.payload}\nlet s = sOn\nnode.status(s)\nchangeColor()\nreturn msg\n\nfunction changeColor() {\n    if (!timerID) {\n        timerID = setInterval(flashStatus, interval);\n    }\n}\n\nfunction flashStatus() {\n    if (--count != 0) {\n        s = s == sOff ? sOn : sOff\n        node.status(s)\n    } else {\n        clearTimeout(timerID)\n        timerID = null\n    }\n}\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":660,"y":660,"wires":[["21da191836f82d24"]]},{"id":"a16012f29786f689","type":"inject","z":"95202e92.939cf8","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"hello world","payloadType":"str","x":520,"y":660,"wires":[["5cc79293a6fbfc60"]]},{"id":"21da191836f82d24","type":"debug","z":"95202e92.939cf8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":true,"complete":"payload","targetType":"msg","statusVal":"payload","statusType":"auto","x":810,"y":660,"wires":[]}]
3 Likes
17

That does have promise.

Thanks.

(oh...)

Nothing against the node.

But flashing the payload may not always be a good idea.
As it isn't a subflow you can't set $env variables as easily.

But maybe in the startup part, define the message to be flashed so if the payload is not good, you can set a message to be flashed.

Just mentioning it.

18

This is what I just bashed together just now.

[{"id":"1010fc4793a4d132","type":"subflow","name":"Debug Alert","info":"","category":"","in":[{"x":60,"y":80,"wires":[{"id":"5cc79293a6fbfc60"}]}],"out":[{"x":340,"y":80,"wires":[{"id":"5cc79293a6fbfc60","port":0}]}],"env":[{"name":"message","type":"str","value":""}],"meta":{},"color":"#DD0000","icon":"node-red/alert.svg","status":{"x":340,"y":130,"wires":[{"id":"10226f443ccc05c3","port":0}]}},{"id":"5cc79293a6fbfc60","type":"function","z":"1010fc4793a4d132","name":"Alert","func":"let timerID\nlet count = 6           // 3 flashes\nlet interval = 500      // ms\nlet sOff = {}\nlet sOn = {}\nlet message = env.get(\"message\") || \"Look at me\";\n\nnode.warn(message);\n\nsOn = {fill:\"red\",shape:\"dot\",text:message}\nlet s = sOn\nnode.status(s)\nchangeColor()\nreturn msg\n\nfunction changeColor() {\n    if (!timerID) {\n        timerID = setInterval(flashStatus, interval);\n    }\n}\n\nfunction flashStatus() {\n    if (--count != 0) {\n        s = s == sOff ? sOn : sOff\n        node.status(s)\n    } else {\n        clearTimeout(timerID)\n        timerID = null\n    }\n}\n","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":190,"y":80,"wires":[[]]},{"id":"10226f443ccc05c3","type":"status","z":"1010fc4793a4d132","name":"","scope":null,"x":200,"y":130,"wires":[[]]},{"id":"6f1fc027a7216aad","type":"subflow:1010fc4793a4d132","z":"aaa025a7d2bb5b14","name":"","x":400,"y":1130,"wires":[["21da191836f82d24"]]}]
1 Like
19

I haven't thought about that, since I don't plan to use the node. I just thought you might want to play with it and modify the code however you like.

Actually, it's easy to use environmental variables in functions. Juse use the env.get function.

1 Like
20

Sorry.

As I said, I wasn't complaining.

I posted the node as a subflow just now.

The other advantage is you can now specify what message is shown.
And the colour the node helps you see it in the flow.