You can not use RED.nodes.getNodeList() in a function node, it'd only work in an "installed" node, but unlike others RED.* runtime functions (https://nodered.org/docs/api/runtime/api) RED.nodes.getNodeList() returns undefined also in a node.
OK, first attempt at getting the node names for each module looks like this:
(
$each(payload.nodes,function($v, $k) {
{
"name": $k,
"nodes": $keys($v.nodes)
}
});
)
Which gives output that looks like this (I've removed the node-red module as it is long):
[
{
"name": "node-red-node-twitter",
"nodes": [
"twitter"
]
},
{
"name": "node-red-contrib-uibuilder",
"nodes": [
"uibuilder"
]
}
]
Or, more compactly:
$each(payload.nodes,function($v, $k) {
{$k: $keys($v.nodes)}
})
which gives:
[
...
{
"node-red-node-google": [
"google plus",
"google places",
"google-api-config",
"google geocoding",
"google directions",
"google calendar"
]
},
{
"node-red-contrib-blockly": [
"blockly"
]
},
...
]
@Colin, so an exported flow (or part of) would look like;
[
{
"id": "29ca2a56.30aea6",
"type": "PID",
"z": "60728902.17e938",
"name": "node-red-contrib-pid",
"setpoint": "",
"pb": "2.5",
"ti": "10000",
"td": "0",
"integral_default": "0",
"smooth_factor": "4",
"max_interval": "1200",
"enable": 1,
"disabled_op": 0,
"x": 150,
"y": 580,
"wires": [
[
"a4e2bfdb.3037"
]
]
}
]
Yes, agree, this would be really useful. Equally important that the actual node name is also shown in the info panel too, instead of just;
It can't use the name field as that is something that the user can set. I think it would either have to be a new field, or perhaps the type field could say something like node-red-contrib-pid:PID where the : would have to be a character not allowed in the type string (if there are any).
Better still:
$sort(payload.nodes.*.nodes.(
$each($, function($v, $k) {
$k & " : " & $v.module
})
))
Gives a list of nodes sorted by node name and each node shows the module it comes from.
[
...
"file : node-red",
"function : node-red",
"google calendar : node-red-node-google",
"google directions : node-red-node-google",
"google geocoding : node-red-node-google",
"google places : node-red-node-google",
"google plus : node-red-node-google",
"google-api-config : node-red-node-google",
"httpin : node-red",
"httprequest : node-red",
"humanizer : node-red-contrib-moment",
...
]
Phew, that was an exercise for the brain on a Sunday morning!
Hopefully, between those examples, you should be able to get a flow that will produce what you need it to. Either add it to all your standard flows or add it to the library so that any user can simply insert it when needed in order to get the data you need.
To improve still further, enhance the flow so that it sends the output to an email address along with some source identifier so that you know which user it comes from. I'm sure you can think of other alternative enhancements.
I've updated the example flow to include all of these examples.
https://flows.nodered.org/flow/eb29b1a45c044706009d2ef47e59f51f
Julian, although useful to obtain a list of nodes, Colin was wanting the node name to be made available in the flow export - similar to my example above, also available in the 'info' panel. So would need to be integrated into core.
Yes, I got that but once started, I couldn't stop until I'd wrangled JSONata into submission!
While having that data in an exported flow would be the best outcome, it doesn't currently exist I don't think. Therefore, having a standardised flow that users can use to export some information would be a second best perhaps? Anyway, that was my thought. Something better than nothing.
Either way, it was a useful exercise for me in understanding how to walk through the complex JSON that is the .config.json file. Hopefully useful to others as well.
1 Like
Seems a good idea, any thoughts/opinions from the developers?
There is a long standing item on the backlog to properly namespace node types in the flow file: https://trello.com/c/ADiPIvGN
This would also allow two modules to be installed that provide the same node type - as they would be distinguishable.
The downside is once the node type includes the module name:
- flow files become much larger with a lot of duplicated information
- flow files are no longer backward compatible; you wouldn't be able to import a new flow file into an older version of NR as they wouldn't know how to parse the type field. The alternative is to add the module name as a separate property... but that then makes issue 1 even worse.
As for at least displaying the module name within the editor when a node is selected; that's easily done and makes sense. I've added a separate item to the backlog for it: https://trello.com/c/jlYseLIH
1 Like
Would a compromise option be to add a list of used modules/nodes as a separate section of the flow JSON? That wouldn't necessarily impact existing flows and flow handlers as the data should be ignored. It also wouldn't add a lot of duplicate data.
Just an idle thought.
I am not sure about 'much' larger.
Just looked at a flow file which has 178 nodes and is 81191 bytes, so an average of 456 bytes. With a new field something like
parent: "node-red-something",
then that might average 30 additional bytes per node, which is an additional 6.5%. Whether that is acceptable I don't know.
