Hi,
like to suggest a few tweaks that could help with debugging
switch(es) to mute warn and error messages: I'm using some nodes which are very chatty, especially when working offline they are spamming the debug window with timeout and error messages disturbing any useful debugging. I can control my own debug nodes but not these. “Current flow only” doesn’t help here(?). The messages can/should still be send to the console.
Same problem as 1.) when filter "current flow” is active limit node.warn and node.error messages from nodes and subflows actually in this flow.
Pause debugging messages: when debugging it could happen that the messages I’m interested in disappear (because the buffer is filled) as long as I investigate the problem. Currently I make a screenshot but this is very limited. A simple pause/play button could help a lot.
While editing a subflow debug messages of the flow(s) the subflow is uses should appear here too when filter "current flow" is active
change node.warn and node.error functions to accept multiple arguments like node.warn("Foo speaking:",msgObject, anotherVariable); to make it possible to bring more information into one debug message. This could be displayed like an array with all arguments. Currently I use multiple node.warn messages.
I’m interested in how others solve this problems. Especially debugging JavaScript inside function nodes. I read that someone is building a temporary custom node for debugging- nice idea but a lot of effort in my opinion. I would love to have a way to use a "real" debugger instead of node.warn functions. My dream would be that it is possible to add a debugger statement into the function to trigger a debugger if connected similar to browsers.
Hi
re 1) any one (or two) in particular - maybe we can get it fixed.
2) yes - while not a bug is probably not what is desired - so a PR to address this would be welcome I think. (And likewise for "selected nodes" mode would also help fix 1)
3) generally just by scrolling the window up it stops the window scrolling off for me ? Or are you getting so many that the buffer gets overfull and old ones disappear ?
4) Does seem to make sense while editing - but if multiple instances of it are in use then it doesn't know which instance is it actually being debugged. They are not subroutines - they are a master instance and copies - so the master isn't actually running anything. (I think there is a special case where there is only one in use (eg just for code collapse/tidy) but we haven't explored that yet).
5) need to be careful with anything that changes API/signature as once done it can't be undone without breaking people - so this would need careful consideration.
Nick was looking at a debug capability with breakpoints etc - but I think that was waiting for "pluggable message routing" that would allow people to plug in how messages pass from node to node (which itself was waiting for the async message passing we shipped in 0.20/1.0) - but would then allow things like inspectors and testers and debuggers to sit between every node.
The debug node can be configured, most people seem to overlook this feature, but you can set it up to display something other than msg.payload, even better, you can even apply jsonata filters to it to only display what you are looking for (not sure if this filters out timeouts/warns)
Once a flow is working: remove the debug node or "silent" it.
Use selected nodes as filter.
I can see advantages to filter within the debug node to get rid of warn/timeouts, then again it is a 'debug' node.
If debugging is required you can always attach a debug node.
Hi, thank you for your quick an elaborate answer. A lot to think about.
Just quickly:
3.) yes, the scrolling stop as intended but the nodes are sometimes filling the buffer up, especially when node.warn had to be placed inside a loop (this is one reason why I came up with 5 to reduce the amount of messages)
And I forgot 6) I know about filter selected nodes but could it be perhaps handy if I can select a debug note in the flow and the debug window filter only the messages from this debug note. The other way around works fine but often I see me clicking through many messages to find the right one. Since a while I name all my debug nodes to avoid this.
node.warn() needs a string or something that can be converted automatically to a string. That is the problem trying to output objects and arrays, not the +
working but not so nice (and difficult to read bigger objects: all in one long line and it is going far to the right that perhaps it is already is in another time zone or climate (Kevlin Henney)
The reason that one doesn't work is because you use the wrong type of quotes. The type of string you use is the template/formatting string introduced to ES6, and in order to use variable inside it through the ${var_name} syntax you have to use backticks rather than regular quotes:
node.warn(`Foo speaking: ${config}`);
It's a tiny difference, but that should work.
Or to put it all together:
Ok, all in one time zone but I think I prefer the double node.warn if necessary. Most of the time I can identify the source by the data and prefer the collapsible lists for bigger objects (the example is only a small one)
Thank you all for the great input and "Marry Christmas".
In Germany we are celebrating on Christmas eve so a lot of preparation is waiting....
Back to your original request - which nodes are causing grief for 1) ?
I have tried several simple use cases and the filter by tab does exclude node.warn and node.error from other tabs... so ...
sorry to come back to you late. Especially this one which connects homematic devices to Node-RED is very chatty.
It is the configuration node (named ccu2) sending this warnings / messages. Normally I disable the config node when I work offline but they also appear (not so often) when working online as the homemeatic hub (called ccu2) is not the best piece of hardware/software I know.
As config nodes are not placed inside a flow the messages bypass the filter (current flow) and appear everywhere. This is why I thought a mute switch would be the easiest solution. But perhaps you can filter them out. If no node placed on the current flow using a config node sending node.warn or node.error messages don`t display them.
Another thing I recognize related to point 3: Even if the filter is set to current flow, and the current flow is not filling the buffer other debug messages (not visible because filtered out) can cause the visible messages disappear.
The logic is clear and appreciated when switching through flows you always see the recent messages but sometimes I would like to push a pause button. Scrolling back a little does the job but in my case don’t last long until the buffer fills up - so read fast and think faster maybe a solution too (or perhaps separate buffers or pointers/counters?)
A “clear all breakpoints” here mute all debug notes could be handy too. My flows looks often like an open heart surgery and are sometimes bigger than the screen ...
A pause button for the runtime could be nice to but that’s another story.
I’m worried that I’m asking for too much - Only some suggestions for future updates.
pause button. Scrolling back a little does the job but in my case don’t last long until the buffer fills up - so read fast and think faster 