Hi,
I need to create a node or area which displays the content of the input event to that node. This requirement is not a dashboard requirement. I have added an scketch of the expected node. Is there a way to do this.
Hi - no. The editor is not meant to be used as a dashboard for runtime state.
The only thing the runtime can do is update the node status - https://nodered.org/docs/creating-nodes/status
Hi Nick (@knolleary),
I had already read multiple times in the past, that the flow editor shouldn't become a dashboard (for displaying runtime state). I'm very convinced that there will be very good reasons for that decision, so I won't argument against it !!!
Although I must admit that Riku Rouvila's node-red-contrib-image-output is a very good aid for me, when I'm experimenting with video in Node-RED:
This way I can tweak my flows, and seeing the results on the video immediately. It has become my private video debugger tool... I could also display the video in other tools (like e.g. the dashboard), but this way is just much easier and quicker.
There is currently no way to expand or collapse the balloon, which could be a nice feature for people that don't want to show it all the time...
P.S. I have no commercial advantage of that contribution, I only created some pull requests to add extra features to it 
Bart
3 Likes
Indeed - node creators have found ways to do it. But we provide no api for it and cannot be held responsible if these nodes break in future releases because we change something.
2 Likes
@BartButenaers thanks for sharing, I completely missed that API !
@knolleary Apart from the fact that the NR team does not officially support RED.comms API and that it might break one day, is there any reason why it's not documented ? I suppose it's there for a reason for the core of NR. Is there any drawback to use to that API for custom nodes ? If so, maybe it should be hidden in some way ? And if not, why not make it official ? Communication between the editor and the runtime using that API (if it's the right way to do it) could be useful in several scenarios, not just displaying images/status/text in the editor.
Well, you've named two very real reasons there.
The Comms channel gives a real-time communication link to the editor. We do not want to flood the editor with real-time messages, so it's reserved for core functionality today.
That may change and we would document it at some point. But it takes considerable time and effort to do that, and it isn't a priority for the 0.20 release.
I think we all realize all the good work you and the rest of the team is putting out there and of course, nobody's expecting that for v0.20 ....
If you allow me, I would like to personally praise the way you (and @dceejay and ?? -- I hope I'm not forgetting someone -- if that's the case consider you're included !) handle all these forums' messages: you are ALWAYS patient, nice and ready to help (even after you've repeated the same message a hundred times). This is something very rare and I know what I'm talking about being a developer myself and having managed forums before (in various domains). Thank you for the way you handle things. And thanks for the whole team for being so receptive to our (sometimes bizarre) suggestions/requirements. 
6 Likes
Hi François,
After my post above, I cannot deny anymore that I'm a big fan of Riku's contribution. But I don't want to encourage developers to start creating such nodes all over the place, because (since Node-RED doesn't offer an out-of-the-box solution) we might end up with lots of different styles and behaviour.
For example in Riku's contribution:
- How to link visually the information to the corresponding node: In the beginning the image was simply displayed below the node, but it wasn't really visible which image belonged to which node. So I added some code to show the blue balloon, with an arrow pointing to the node.
- What if no information is available: I created a pull request to show a static image when no stream available. But for other kind of data, other 'no data' visualisation might be required. Or do you just show an empty balloon?
- Does the balloon need to be resizable: in case of images, I wanted the balloon to be resizable. But in some other cases this is perhaps not required/allowed.
- Does the information/balloon always needs to be visible: currently the image balloon is not collapsable, so it is always visible even if you don't want it.
- Does the data always need to be pushed to the balloon: I added a pull request to have a button, to pause or resume data pushing. And suppose it could be collapsed, perhaps data pushing should be paused automatically when collapsed (but if data gaps are not allowed, it might be required keep pushing).
- ...
If every node developers invents it's own style, we will mess up the flow editor. So please keep it consistent ...
Bart
1 Like
How much data are we talking ? You do know that the debug node can display its input directly underneath itself rather than in the debug window ??
Also a number of other nodes do the same thing (such as the schedex node so you could create your own - if the status area is enough for you
Craig
Sure, just give it a short name.
But I think you mean to a smaller icon. Which I probably wouldn't use even if it were available because it would make my flows virtually unreadable. (Not that I can read them a week after creating it). You can also reduce a group of nodes to a subflow, and that is represented by a single balloon.
Indeed, would have been better if there was a (uniform) way of displaying or hiding the blue balloon. E.g. in the image-output node, you don't always want to show all camera's. You could workaround this by removing those nodes in the flow, but then you have to redeploy ...
Or maybe if the images were in the sidebar (like other debug) then they wouldn't be in the way 
1 Like
How can I show the debug note input directly as a status message?
This is what I'm searching for.
Thank you
Upgrade to latest NR, you have it there as a possible setting
1 Like
Thank you. I overlooked this change on the last updates.
