Node-red-contrib-data-view

Share Your Nodes
1

An interesting new node by @mike Blackstock, which I'm sure will start a debate...
node-red-contrib-data-view
Regardless of the politics, I think it's a long awaited welcome addition, which helps bridge the gap between editor + dashboard.

chart
chart719Ă—222 12.7 KB

(who is gong to be the first to quote the mantra?)

4 Likes
2

Hi Paul,
I had also planned to discuss this node today here :wink: Although the flow editor is no dashboard, I just love this new node...
Bart

2 Likes
3

To quote part B of the mantra - don't forget "this is using an undocumented API" that could change at any time. While there are no plans to do so there are also no guarantees we won't. So use at your own risk.

4

Yes, the editor should be not a dashboard. But debugging is much easier in the editor than to use the dashboard.
Often also the user's are different for the dashboard and they will be confused if there are exists debugging tabs.
Such debugging helper should become more official. Perhaps an official API could already help.

5

There is no data optimisation so another way to crash the browser. Not the best thing to expect in the middle of developing your flow...

6

Although I (try to) understand you guys don't want to encourage this kind of features, I still think it is a pity that we end up now with a bunch of nodes that all have to implement identical boilerplate code (to show their data in an unofficial popup window). And if a part of the community don't want to use their flow editor as a dashboard, they simply don't install this kind of nodes.
But for the other part of the community (perhaps I minority to which I belong...) it would be really useful if popups would be out-of-the-box available...
Now my popularity will below freezing point probably...

2 Likes
7

I like this node, it is useful to me.

8

Funnily enough, I was just talking to Dave the other day about having more 'interesting' data visualisation options in the Debug sidebar.

The part I find wearing is the fact I spend all my time trying to improve Node-RED and no-one else seems interested in helping. You all wait for me to do the hard work to design the API and implement the feature, and in the mean time you carry on publishing nodes using undocumented APIs that you know we'd rather you didn't use and complain there isn't a proper API for it.

So yes Bart - it would be great to have a proper API for a node to do things like this. Which item on the back log should I remove so I can do the work on this API first? Or does someone want to help do the work to sketch out what that API could be?

2 Likes
9

Ok if it is a matter of your time, then you got me. I really thought - due to previous discussions - that it was more about it not fitting into the Node-RED philosophy...
But since I cannot offer you more help on the core, I will take your concerns into account before starting new discussions in the future. Don't want to put you under extra pressure, or being greedy...
Case closed.

10

We have requirements to allow for more customisation of the appearance of the flows and nodes. This isn't for individual users of Node-RED, but projects that want to adopt/re-use the editor, but have quite specific requirements on look/feel of the flow diagrams.

So at some point next year, all of the flow drawing code is going to be ripped apart and made pluggable. It's this work that might break the nodes that do extra-curricula drawing in the workspace.

But it's also that work that could allow for vanilla Node-RED nodes to do something 'extra'.

At this point, there is no design work on any of this. I say next year as I hope to be able to get to it at some point in that time frame. It all depends on what progress we are able to make on everything else.

3 Likes
11

Thanks! I certainly seemed to have stirred things up with a bit of work I did over the holidays to get back into Node-RED development -- I just thought it would be fun to try :slight_smile: I've already had some good feedback. Yes, you should use this at your own risk given it depends on how things are today.

@knolleary - I'll be sure to track changes to the flow drawing code to make sure this node keeps up as best I can.

3 Likes
12

Because you engineered the code, why not tailor it to the node-red standards and perhaps, with the help of this community, create even a dashboard widget. So, once the code is sanitized by the administrator, can even be added to the project's core.

BTW, thanks for sharing. :beers:

13

This is a very early version of the node, and reading the author's last comment in the post above, I'm sure it will eventually be aligned to the node-RED framework. Just give it some time.

We already have this facility in the dashboard (chart node??) So no need to create a duplicate.

Not everyone will want/need/use this node, so I don't see the point of adding it to the core, when it can easily be added by using the flow library.

4 Likes
14

To go back to a kind of requirements engineering and a more general view:
We are talking about an extended debugging functionality ("signal monitoring"), which extends the debug tab of the NR editor.
In PLC programming systems you also have such windows. They are called like "message windows" (similar to the debug tab or the log output), then you often have a "watch window" and a "trace function". The described node points more to the trace function.
So the basic discussion could be to generally think about signal monitoring in the NR editor. This could also contain a discussion of a watch window (resp. watch tab). This seems to be easier to implement as a complete trace function, because discussions on trace functionalities directly give us growing requirements like zooming/scaling (x- and y- direction), shifting zoom areas horizontally, cursors with measuring functions, etc.. I.e. all these bells and whistles a typical oscilloscope has.

... I wanted not to open the pandora's box. :slight_smile:
NR has come to a very good low code programming system in the past, we are wishing/dreaming on a veeery high level!

15

Just my 50 cents here.
Along NodeRED I'm also a long time user of other graphic programming languages, like Codesys (for PLC) or Matlab/Simulink.
And during recent years these tools recently evolved into same philosophy, especially Simulink - adding more and more Dashboard-like features directly into program. Before one had to create separate GUI for controlling the application, and now all kinds of switches, bulbs, gauges and graphs are implemented directly in flow.

So this feature in NodeRed will be definitely handy, as it is becoming very common.

1 Like