Why debug nodes can only show 'msg' messages? This seems very restrictive and limited. Why can't global or flow context variables be displayed by a debug node? Or is there a way to do it?
Set the view to expression, and request them through JSONata. $flowContext('<name of flow variable>') is the syntax to do so I think. An alternative is looking at those from the context tab in the sidebar:
2 Likes
I don't think anyone has ever had a need to display them in a debug node.
I imagine it wouldn't be too hard to add the option in - but what is your use case?
(Lots of things are wanted but developers only have so much time so they prioritise requests)
You could just precede a debug node with a change node and set msg.payload to whatever flow/global context value you want to send to the debug pane
or
Adding change nodes is just a band aid IMHO. From design perspective, the more elegant design is to add global, flow, etc. to debug nodes. This is a consistent and intuitive design step.
Is it a priority? Yes and No. Yes, in that it would make flows less complex and more consistent. I am sure many users would benefit. No, because there are several ways to deal with the issue or limitation of this debug limit. I prefer to use a function node and using node.warn to provide better flexibility in reporting to the debug window. Thus I have one node only in flows per, rather than the classic change and debug node scenario.
If you have so many context variables that you regularly need to show them like that then I believe that you would benefit from refactoring the design and getting rid of them completely.
You can find the variable values in the context tab.
If you need point in time values printed to the debug window instead of looking at the context viewer, then, as well as the solutions already offered (using JSONata, using change nodes before a debug) you can also use a function node in place of a debug and do a call to node.warn
Function node...
node.warn([
"flow.counter", flow.get("counter")
]);
return msg;
An added benefit is the function node can be "inline" so there is no branching (no cloning of messages)
E.g.
Node>node>debugfunc>node>debugfunc>node>normaldebug
Why is everyone ignoring the very first reply from @afelix that explains how the debug node can already be configured to display a value from context when triggered?
You don't need a change node, you don't need a function node, you don't need to refactor all your flows to remove any use of context.
You can do exactly what @afelix suggested in the very first reply.
1 Like
I don't think people are ignoring @afelix Nick. I certainly didn't.
It's not a bad thing to offer alternative perspective and solutions. For example, the op may not realise there is a context viewer. The op may not know about node.warn(). There is no harm in offering advice and alternative solutions IMO.
And as @Colin points - a redesign could possibly the best answer of all. I lost count (in my early experience of NR) of the number of times I offered someone a working solution using context variables only to be told by many folk (including senior members) that I should use a join node or pass it in the msg etc.
Well, personally, I don't understand what @afelix is saying what is needed to be done to get flow/global changes appearing in the debug pane 
In that case, ask for explanation so I can explain more. Apparently I could explain more to it 
When you set a debug mode to type
Expression, you can enter a JSONata query to have it output the data. Since a JSONata query supports flow and global through $flowContext('<name>') and $globalContext('<name>') you can use those to display the items, or even more complex structures. These are functions added by Node-RED, and as such they're not documented in the JSONata official docs. They are however documented in the Expression editor:
For example, say you've a flow context variable like I showed in the screenshot of my first post in this thread ribw_aanwezigheid, to view the content of that (an array with objects for every item, it's a CSV documented stored in the context for easy lookups), you can set your debug node to Expression mode, and the query to $flowContext('ribw_aanwezigheid'). Now if a message is passed to this debug mode, rather than showing the payload or full message object like the other options would do, it would output the value of this flow context variable.
Heavily redacted output to that (this flow handles expected presence of staffers at a care home):
6 Likes
Won't that only show the value at the moment you trigger the debug node? It won't automatically display a new value when the context value changes.
Which brings me back to my favourite hobby horse, one of the major issues with using context is that there is no way of knowing when a value is updated other than polling it. It is best (IMO) to avoid context except when absolutely necessary. So far I have never used it at all, apart from fixed data initiallised in settings.js
1 Like
If you use the context data sidebar, you can set it to auto refresh for when the values update. If you have a pressing need to know the direct value without polling that's the solution already there for you. Why add them in the debug sidebar again? 
On the other hand, I do use context quite a bit, but always for specific situations: storing oauth tokens that are only valid for XX hours and need to be refreshed with tokens you get from it, storing files I read in and need aspects of without needing to read in the file again at runtime, unless I request for a refresh (those files, like the one above, are valid for a month or longer). Storing combinations of username/chatid when working with telegram bots. I could hardcode them, but I prefer not to. I wait for the first message to come in, check if the user is authorised by the bot, and then store the data in a context variable to reference when needed. There's plenty of reasons where Context would be preferred over hardcoding, or where it could be used effectively. No reason to banish them from all your flows because of the polling aspect.
3 Likes
You are right, polling for changes in context is an anti pattern best avoided.
And as @afelix says, that in no way invalidates all of the other uses of context.
While I agree, node.warn() is likely the most flexible. I disagree that use of the context solution as discussed is a viable option for most users, it is IMHO especially a barrier to newer users. You are asking someone to spend quite a lot of time to figure it out, and used to it, etc. When it is clear that just adding global and flow option to debug is the intuitive and logical solution. Please, lets make things easier for the most users, rather than referring to a buried solution. Now please, I am not being critical of the option, I find it quite interesting. But it took me 30 minutes of reading and playing to get it to work, and I already had a clue of what and how do to it. Whereas a typical beginner would be pulling hair out and giving up in the same period of time. Frankly, I just don't understand why it can't just be done, add global and flow to debug along with msg, regardless of the various options and solutions noted above... It just really would be the most user friendly straight forward thing to do IMHO.
I think context, flow and global variables are very useful when used with care. Whatever you think is care.
It's not what a beginner should start with. And you should name them carefully to help you later when you think, "what and why and where do I use this???" Otherwise it (your flows) could evolve to something similar to a badly written old Basic program with a lot of GOTO jumps, making it almost impossible to track
I use them for example as state information where I need a certain state information in multiple tabs. I think I could re-work the flows and use a large number of link nodes instead. But it would definitly make my flows look more messy. Do you prefer a shiny outer finish and all he "cables" under the hood?
What would help in understanding a "flow design" would be to have a feature in the "Context Data" view to show all referrals to a specific context data variable
1 Like
Do you use MQTT? If so then you could consider using MQTT for storing that state information, with the added benefits that the tabs get notified on change, and it is easily made persistent by the use of Retained topics. Plus the state can be across multiple node-red (and dashboard) instances if that is appropriate.
2 Likes
How do you then query the current state?
Yes MQTT can be used to notify you when something changes, but if you need a flow to be able to refer to the current state, you need to have it stored somewhere accessible.
I'm sorry but MQTT is not a drop in replacement for context. They both have their uses and can compliment each other.
But that is not what this thread is about. Please keep it on topic - how the Debug node could be made to work with context more intuitively.
3 Likes
