Thoughts on NR Improvements from a Newbie

[Julian Knight]

Scott  made the mistake of asking so here it is! The "quick" list of thoughts for NR!

Just my view of course with only a few days working seriously with NR so they have probably all been covered in the past.

General Improvements

• Debug window to have pop-up window with pretty JSON output or at least a link to display it. Currently really hard to debug msg content, especially when it gets bigger & more complex.
  
• Search for object by code, e.g.: 3e610b62.c19ef4 - helpful when you have a node you forgot to name but that is reporting an error!
  
• Save debug output switches (without needing a Deploy) - I think I've seen another discussion about this.
  
• Send/Receive msgs to itself (e.g. event based flows without needing MQTT broker) - via WS, internal events? A good way to avoid the desire for while loops? And to keep areas of concern separated.
  
• Socket.IO instead of raw web sockets - specifically to enable secured sockets?
• Secure login to admin portal. Out of the box. Far too much of the IoT world is ignoring security!
  
• Move admin to /admin by default and present a default front page. Making it easier to present a full application for new Node-Redders.
  
• HTTPS by default (with default certs that need to be changed)
• Move remaining node templates to NPM - currently not clear which are which
• Easier external edit for Function and Template nodes - already discussed in the previous thread.
  Most likely a non-starter.
  

Ideas for New Nodes

• Time formatter - should be an easy one. Could use Moment.JS. Allow any allowed date/time format. Input field should be specifiable as should output field. Input should allow text. This is a really common transformation requirement!
• XML output - many web API's still demand XML.
  
• RSS output - shades of Yahoo! Pipes!! Possibly a nice way to collate and integrate many different
  
• A node to create/manage configuration nodes - save editing config files for static data
• Wrapper node - to keep node-sets together - with a title - cut/copy/move the wrapper keeps all the content together
  
• A "Dependency" node that doesn't trigger output until a set of inputs have been collected. This would allow an event to be triggered only after receiving several pieces of non-related or semi-related data (e.g. wait for 2 different web API's to return data before triggering output).

Specific Nodes that could be enhanced

• Better comment nodes - with HTML rich text - it is currently hard to document flows!
  
• Enable reordering of tests in Switch node - currently annoying when you started with a couple of entries plus an otherwise and then want to add something to the middle.
  
• More flexibility for JSON/XML nodes - ability to act on different parts (or whole) of msg
• MongoDB: Merge data into an existing entry - currently "update" seems to destroy any existing data so I currently have to have a node to read the existing data, combine the new data and then save the data.
  
• Ping that allows an external trigger. Also that allows multiple addresses - useful for checking if machines are alive. An ARP version of ping would also be very useful to enable checking if a SERVICE is alive on a device

Regards, Julian.

[Nicholas O'Leary]

Hi Julian,

thanks for the feedback. A number of these have been discussed before, some are on the todo list, some haven't come up before.

Rather than provide a blow-by-blow commentary on each one, I'll let other chime in with thoughts. I will just say that security around the editor and admin api is about to get a big enchancement... stay tuned ;)

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Penrose]

On Tuesday, January 27, 2015 at 10:13:14 PM UTC+11, Julian Knight wrote:

Scott  made the mistake of asking so here it is! The "quick" list of thoughts for NR!

Just my view of course with only a few days working seriously with NR so they have probably all been covered in the past.

General Improvements

• Debug window to have pop-up window with pretty JSON output or at least a link to display it. Currently really hard to debug msg content, especially when it gets bigger & more complex.
  

+1 

• Search for object by code, e.g.: 3e610b62.c19ef4 - helpful when you have a node you forgot to name but that is reporting an error!
  
• Save debug output switches (without needing a Deploy) - I think I've seen another discussion about this.
  
• Send/Receive msgs to itself (e.g. event based flows without needing MQTT broker) - via WS, internal events? A good way to avoid the desire for while loops? And to keep areas of concern separated.
  
• Socket.IO instead of raw web sockets - specifically to enable secured sockets?
• Secure login to admin portal. Out of the box. Far too much of the IoT world is ignoring security!
  

Not sure about this one, or the SSL. Most sensor networks are not secure, as such need to be on a secure network. The advantage of node-red is that it can be on that network, rather than the cloud. If it was default, I would have had to disable it.

• Move admin to /admin by default and present a default front page. Making it easier to present a full application for new Node-Redders.
  

+1 

• HTTPS by default (with default certs that need to be changed)
• Move remaining node templates to NPM - currently not clear which are which
• Easier external edit for Function and Template nodes - already discussed in the previous thread.
  Most likely a non-starter.
  

+1 

Ideas for New Nodes

• Time formatter - should be an easy one. Could use Moment.JS. Allow any allowed date/time format. Input field should be specifiable as should output field. Input should allow text. This is a really common transformation requirement!

Easy, would you just change payload in and out? Or is it better to add this as a standard loaded in function to allow more flexibility ? 

• XML output - many web API's still demand XML.
  

There is already an XML out, and Template - how would you do this one better? Since XML is infinite - how could you do something better than a template? 

• RSS output - shades of Yahoo! Pipes!! Possibly a nice way to collate and integrate many different
  
• A node to create/manage configuration nodes - save editing config files for static data
• Wrapper node - to keep node-sets together - with a title - cut/copy/move the wrapper keeps all the content together
  

+1 - go with you comment suggestion 

• A "Dependency" node that doesn't trigger output until a set of inputs have been collected. This would allow an event to be triggered only after receiving several pieces of non-related or semi-related data (e.g. wait for 2 different web API's to return data before triggering output).

+1 - I have achieved this myself using context in function. But I think you could generalise, e.g. drop down of types "wait for count", "wait for all until delay" - the problem is how  to combine - e.g. just one output (which one) or combined (how to combine). Could be hard to generalise.

Specific Nodes that could be enhanced

• Better comment nodes - with HTML rich text - it is currently hard to document flows!
  

+1 

• Enable reordering of tests in Switch node - currently annoying when you started with a couple of entries plus an otherwise and then want to add something to the middle.
  
• More flexibility for JSON/XML nodes - ability to act on different parts (or whole) of msg
• MongoDB: Merge data into an existing entry - currently "update" seems to destroy any existing data so I currently have to have a node to read the existing data, combine the new data and then save the data.
  
• Ping that allows an external trigger. Also that allows multiple addresses - useful for checking if machines are alive. An ARP version of ping would also be very useful to enable checking if a SERVICE is alive on a device

+1 - I had trouble with this too, I was surprised it wasn't just an input, and use an external timer if you just want a regular ping - it would be then more generalised. So this one would be actually a simplification.

Great list.

Scott 

[Julian Knight]

Wow, enchanted Node-Red - I can't wait!!! :)

[Julian Knight]

Hi Scott, many thanks for that feedback, good to know I'm not totally off the mark. I'd added a couple of comments below.

On Tuesday, 27 January 2015 11:54:12 UTC, Scott Penrose wrote:

On Tuesday, January 27, 2015 at 10:13:14 PM UTC+11, Julian Knight wrote:

Scott  made the mistake of asking so here it is! The "quick" list of thoughts for NR!

General Improvements

...

• Secure login to admin portal. Out of the box. Far too much of the IoT world is ignoring security!
  

Not sure about this one, or the SSL. Most sensor networks are not secure, as such need to be on a secure network. The advantage of node-red is that it can be on that network, rather than the cloud. If it was default, I would have had to disable it.

JK> And that is really my point. Too many are totally open and open to abuse. That's why I've chosen the TI base Ciesco radios for my own sensors. They have encryption available on-chip. As most of us are using Wi-Fi at least for parts of our home networks, using unencrypted data streams makes us wide open to monitoring and remote abuse. As we get carried away with our projects, there are going to be more and more incidents until people realise the dangers. Imagine going away for a couple of weeks and coming back to find the heating turned on full and all the lights on. Or someone sniffing your network, finding when you are out and disabling your home-built "alarms"...

This is not a theoretical risk nor is it a small one.

Ideas for New Nodes

• Time formatter - should be an easy one. Could use Moment.JS. Allow any allowed date/time format. Input field should be specifiable as should output field. Input should allow text. This is a really common transformation requirement!

Easy, would you just change payload in and out? Or is it better to add this as a standard loaded in function to allow more flexibility ? 

JK> Yes, I expected this would be easy and it may well be my first node if I can ever find enough time to do it and someone hasn't beaten me to it.

I had been thinking along the in/out scenario though I'd prefer to offer some flexibility so I would be able to specify the input  object to transform & the output object to place. Having Moment.Js or similar library also loaded and ready for use in Function nodes would be a nice side benefit but the real benefit is for non-coders. After all, I can require the library from NR's config file if I need it in code.

• XML output - many web API's still demand XML.
  

There is already an XML out, and Template - how would you do this one better? Since XML is infinite - how could you do something better than a template? 

JK> Oops, did I miss that one? I thought the XML output node actually transformed the XML to JSON - is there another? I guess though that I wasn't thinking that one through too well. Perhaps there is some way to translate JSON to XML? Otherwise, as you say, you could use a template but I think most people would find it quite difficult to do.

Related: does the template node allow full access to Mustache? Can I have repeating elements - for example, if I had input JSON that included multiple time entries [ { ts: 1702, value: 40 }, {ts:1706, value 42}, ....] could I easily translate that unknown number of repeats to an unknown number of XML entries within the larger XML template?

• RSS output - shades of Yahoo! Pipes!! Possibly a nice way to collate and integrate many different
  

JK> This was what I was really thinking about when I was considering XML out.

• A "Dependency" node that doesn't trigger output until a set of inputs have been collected. This would allow an event to be triggered only after receiving several pieces of non-related or semi-related data (e.g. wait for 2 different web API's to return data before triggering output).

+1 - I have achieved this myself using context in function. But I think you could generalise, e.g. drop down of types "wait for count", "wait for all until delay" - the problem is how  to combine - e.g. just one output (which one) or combined (how to combine). Could be hard to generalise.

JK> I can certainly see how to do this in a Function node but that kind of goes against the grain doesn't it :)

I don't think we should over complicate it. Wait for n messages of a given topic with an optional timeout would be great. As with my previous comments, the ability to specify the input object in case you couldn't use msg.topic would be good.

For output, I'd say that sensibly, one 1 output msg is logical. The easiest approach probably being to make msg.payload an ARRAY, each entry containing the input msg.payload or the original msg depending on a select flag as with other nodes.

...

Great list.

JK> Thanks Scott!

[Dave C-J]

Keep it coming guys - all good stuff.

XML node is currently two way - XML string in -> JS object out .... JS object in -> XML out

(within the constraints of the underlying library of course...)

There is a node-red-contrib-jsonpath node that does allow clever selection from json objects etc

Easiest way to work out what object to send is to pass in a known good xml ... grab it - then use that as a template (either mentally or physically) to create your own object to pass back back out. (or template the xml directly as already mentioned) - and yes feel free to try full mustache... should work.

looking forward to seeing the moment node :-)

A scatter/gather node pair is on the to-do list. 

[Julian Knight]

Ah, good pointers Dave, thanks. Sounds like some documentation updates may be called for? It wasn't even clear to me at first that the XML node converted to JSON :} Let alone that it would work the other round as well. The ws: vs wss: issue in the other post could also do with being in the documents. I think I need to go back and do some reading! Do you take contributions to the WIKI?

I've seen JSONpath, have it installed but not yet had time to play with it.

Like the suggestion for grabbing a template - be even easier with some nicely formatted debug output - hint, hint :)

Damn, now you've laid down the gauntlet for me to get coding a moment.js node! Bang goes my new years resolution of early nights!!

I can see that I'm going to have to reinstall my NR instances to take the latest code. :(  Don't know when I'm going to get time to build out my other home sensors at this rate!

[Dave C-J]

We tend to not really use the wiki... but yes either suggestions and/or pull requests to the nodes and or docs welcome (as long as we have a CLA in place).

Yes we hear you (all) re debug :-)

re moment node - yes we like to share the "fun" :-)

[Julian Knight]

Ah, gotta love Big Blue! CLA (chuckle). I've printed one off & I'll submit it. Do you really want the original via snail mail though?! So last century!

Now you've got me all nostalgic! I've been dealing with IBM one way or another since I first started in IT - 1978 as an intern!! Even got an article published in one of IBM's magazines once. About Lotus Notes I seem to recall.

OK, exiting "old fogy" mode  ...  time to dust of the coding fingers.

[Dave C-J]

we accept scan/email from camera phone these days ;-)

[Oliv']

Lot of good idea, especially the pop-up for the debug window

On Tuesday, January 27, 2015 at 12:13:14 PM UTC+1, Julian Knight wrote:

Socket.IO instead of raw web sockets - specifically to enable secured sockets?

 I am not sure if I understand this request well, but we can already use secured socket.

[Julian Knight]

Thanks Oliv'

Actually it wasn't at all clear that just putting NR onto HTTPS would also move WS onto WSS. Luis pointed it out to me having read the NR code! Not something I have the time or inclination to do!!

There are some other issues though I think with using raw ws: I went through them with Luis. I need to test them before I write up a more complete picture though because I might be totally wrong. The two issues I'm looking at are:

1. I'm not sure whether ws: connections can recover automatically from a disconnection. I think that Socket.IO can. I might well be wrong there of course and I'm happy to be corrected. But I've already noted that, if I connect to my home monitoring page (at least from a mobile device, iOS) then leave for work (e.g. loose the network connection) then come back, the ws: doesn't reconnect, I have to reload the page. This would be confusing for the non-technical members of my household.
2. ws: is often not accessible from corporate networks where you negotiate your way through may weird and wonderful intermediates such as DLP, IPS, Proxies, Firewalls, and Routers. Socket.IO starts with a simple HTTP(s) connection and then tries to upgrade the connection to something better so it nearly always works in some form or another.
   

[Nicholas O'Leary]

Julian,

a raw websocket object does not have anything in it to automatically reconnect a lost connection. But just as socket.io does, node-red has code around the websocket object we use for realtime comms between the editor and the runtime, to re-establish the connection - it retries every couple of seconds whilst the connection is down.

The use of websockets over some networks is an issue. In my experience, accessing node-red over https (and thus wss under the covers), often alleviates the problem as the networking kit between me and the server is less likely interfere when the connection is encrypted. But I'm sure there will still be some combinations of kit that aren't helped by that.

Nick

--

[Julian Knight]

Ah, thanks for that Nick, valuable information. Much to learn!

In the spirit of getting things to do only what they were designed for (do one thing and do it well), I might stick with my plan to create a separate Node.JS server thread to serve up an actual full-fat web site with login and strong security. But it is certainly good to know that NR has the core stuff covered. I'm rather anal about this - at least in part because I am IT Security lead for a major institution!

[Dave C-J]

In that case - this may be useful - http://nodered.org/docs/embedding.html

[Julian Knight]

Thanks Dave :)

Though actually I'll probably keep 2 Node services running. One for the web site and one for NR. The reason for that is that I don't have to worry if I accidentally mess up my front-end security, at least the back end wont be impacted. Maybe too paranoid - I'll think about it for a bit.

[Emil Oberg]

Here's my random comments!

Den tisdag 27 januari 2015 kl. 12:13:14 UTC+1 skrev Julian Knight:

Scott  made the mistake of asking so here it is! The "quick" list of thoughts for NR!

Just my view of course with only a few days working seriously with NR so they have probably all been covered in the past.

General Improvements

• Debug window to have pop-up window with pretty JSON output or at least a link to display it. Currently really hard to debug msg content, especially when it gets bigger & more complex.
  

I concur, and this shouldn't be hard to implement at all. While we're talking about it, it'd be an easy thing to also add prettier output I quickly scanned the code and as it's already using util.inspect it should be straight forward to add colors to the output.

• Search for object by code, e.g.: 3e610b62.c19ef4 - helpful when you have a node you forgot to name but that is reporting an error!
  
• Save debug output switches (without needing a Deploy) - I think I've seen another discussion about this.
  
• Send/Receive msgs to itself (e.g. event based flows without needing MQTT broker) - via WS, internal events? A good way to avoid the desire for while loops? And to keep areas of concern separated.
  

Interesting, I haven't had the need for this myself. What use cases do you see? Is it purely visual ones where you don't want to drag a wire from one node to another? For me, emitting an (internal) event and receiving it is just what we're doing by dragging the wire.

• Socket.IO instead of raw web sockets - specifically to enable secured sockets?
• Secure login to admin portal. Out of the box. Far too much of the IoT world is ignoring security!
  
• Move admin to /admin by default and present a default front page. Making it easier to present a full application for new Node-Redders.
  
• HTTPS by default (with default certs that need to be changed)
• Move remaining node templates to NPM - currently not clear which are which
• Easier external edit for Function and Template nodes - already discussed in the previous thread.
  Most likely a non-starter.
  

Obviously agreed on this as I wrote a node for it ;)  

Ideas for New Nodes

• Time formatter - should be an easy one. Could use Moment.JS. Allow any allowed date/time format. Input field should be specifiable as should output field. Input should allow text. This is a really common transformation requirement!
• XML output - many web API's still demand XML.
  
• RSS output - shades of Yahoo! Pipes!! Possibly a nice way to collate and integrate many different
  
• A node to create/manage configuration nodes - save editing config files for static data
• Wrapper node - to keep node-sets together - with a title - cut/copy/move the wrapper keeps all the content together
  
• A "Dependency" node that doesn't trigger output until a set of inputs have been collected. This would allow an event to be triggered only after receiving several pieces of non-related or semi-related data (e.g. wait for 2 different web API's to return data before triggering output).

Specific Nodes that could be enhanced

• Better comment nodes - with HTML rich text - it is currently hard to document flows!
  

I'm hijacking that thought! I cloned and modified the comment node to be able to place it on a wire (not on NPM but I can put it up there). Technically speaking it's a node which takes a input and relay it to the output without doing anything with it. Of course this adds some overhead, but a microscopic one. However, this is really a hack-ish way of solving my real problem. My problem is that if I have a function with 10 different outputs, I want to be able to name the outputs (and maybe inputs) and make the names show on mouse over or something like that.

It'd be great if we could name the inputs. Maybe something like this:

    RED.nodes.registerType('',{

        inputs:0,

        outputs: ['orSuccess', 'onError']

    })

or maybe even

    RED.nodes.registerType('',{

        inputs:0,

        outputs: [

            {

                name: 'orSuccess', 

                desc: ''

            },

            {

                name: 'onError', 

                desc: 'This might be happening because the http endpoint is down...'

            }            

        ]

    })

That we we could have backwards compatibility, checking if inputs/outs are numbers or arrays/objects.

That being said, I'd rather go for markdown than html rich text, but thats just me.

• Enable reordering of tests in Switch node - currently annoying when you started with a couple of entries plus an otherwise and then want to add something to the middle.
  
• More flexibility for JSON/XML nodes - ability to act on different parts (or whole) of msg
• MongoDB: Merge data into an existing entry - currently "update" seems to destroy any existing data so I currently have to have a node to read the existing data, combine the new data and then save the data.
  
• Ping that allows an external trigger. Also that allows multiple addresses - useful for checking if machines are alive. An ARP version of ping would also be very useful to enable checking if a SERVICE is alive on a device

If I'm not missing anything, making ping fire on input should be a 5 minute thing. But as for arping goes... is that even possible on Windows?

 

Regards, Julian.

[Julian Knight]

Interesting idea Emil.

We still need the better comment node. Like the thought of using Markdown though being rather set in my ways, I can never remember the syntax! I'd rather be using a UI and I believe NR already has one built in if I remember from that various libraries included. We need to remember that this is a tool not just for us techies! Still MD as an option would be nice too, especially Github flavored as that is rather more comprehensive than the standard variety.

I love your idea of being able to name and add descriptions to outputs, that's brilliant. It would really add value to the UI.

Re Ping, I agree, it should be a trivial change. I'd like to expose the command line parameters too since the defaults used don't work in busybox which uses ash rather than bash and simplified tools.

Re arping: There are several implementations for Windows including this one. However, on reflection, most of what you want to do with arping would be to check if a TCP service is alive. You can do that really easily in Node.JS with a TCP call so a native arping command isn't needed as long as you can live without the mac address stuff. So a node to wrap up firing multiple TCP connections (addres:port) and waiting a set time for a response from each (using non-blocking setTimeout & an internal flag) would be pretty easy to do. You could also have an option to wait for all responses or fire a msg for each response. Perfect for a mini service monitoring tool.

On Thursday, 29 January 2015 10:35:17 UTC, Emil Oberg wrote:

Here's my random comments!

• Better comment nodes - with HTML rich text - it is currently hard to document flows!
  

I'm hijacking that thought! I cloned and modified the comment node to be able to place it on a wire (not on NPM but I can put it up there). Technically speaking it's a node which takes a input and relay it to the output without doing anything with it. Of course this adds some overhead, but a microscopic one. However, this is really a hack-ish way of solving my real problem. My problem is that if I have a function with 10 different outputs, I want to be able to name the outputs (and maybe inputs) and make the names show on mouse over or something like that.

...

 

That we we could have backwards compatibility, checking if inputs/outs are numbers or arrays/objects.

That being said, I'd rather go for markdown than html rich text, but thats just me.

• Ping that allows an external trigger. Also that allows multiple addresses - useful for checking if machines are alive. An ARP version of ping would also be very useful to enable checking if a SERVICE is alive on a device

[Nicholas O'Leary]

For the Comment node, I propose we only go so far as support markdown formatting, rather than full HTML, for the following reasons:

 - markdown is plain-text readable - it doesn't have to be rendered to be legible. html isn't really.

 - for the novice user, the leap from text to markdown is minimal and can be largely ignored if plain text is good enough.

 - rendering arbitrary html in the editor is risky - especially if you're importing random flows from the internet. We'd have to sanitise it etc etc.

This doesn't rule out a future where we may decide to handle HTML, but I think we can largely satisfy the requirement without it.

I've raised https://github.com/node-red/node-red/issues/544 to track this piece.

--

[Julian Knight]

Oh well, can't say I'm that happy with the approach but I understand the reasons. It isn't the end of the world.

[Nicholas O'Leary]

Julian, had a quiet few minutes, so you can now reorder the rules in the Switch node by dragging them around.

Nick

On Thu Jan 29 2015 at 14:28:22 Julian Knight <j.kni...@gmail.com> wrote:

Oh well, can't say I'm that happy with the approach but I understand the reasons. It isn't the end of the world.

--

[Dave C-J]

New comment block inbound to github any minute now...

The tip has a link to markdown syntax document (on web) so Julian can "get down" with the syntax ;-)

As Nick said - we're not allowing raw html to prevent code-injection for now.

(I also made the HTML help link to Cheerio docs)

[Julian Knight]

Oh my! Nothing for ages and then two come together (3 in fact)! A little English bus humour there for folks in less civilised countries :)
Nice work.

Now I'm really going to have to reinstall - drat you guys!

Thankfully I can follow up with v1 of my moment node. Got sidetracked trying to make the string input formats more robust using a plugin but it didn't work so it is coming out. Doing a couple of final tidy ups and will publish to NPM properly in a few minutes.

Then I'll go and reinstall everything from the Github repo. :(

[Nicholas O'Leary]

On the mongo node front, it is possible to update a document in place - but you have to do it the mongo way, using the $set operator to identify which fields you want to update: http://docs.mongodb.org/manual/tutorial/modify-documents/

Nick

--

[Julian Knight]

Ah, thanks Nick. I wondered if I'd done something stupid like that.

Good job I don't earn a living as a programmer!

[Julian Knight]

By the way Nick, just read your last blog post - awsome!

I want your job!!

I'd have left a comment but it requires yet-another-login(tm) :( You might want to try using Disqus?

Anyway, I love the idea of an IoT "chatroom" where the devices chat away to each other. Really made me chuckle. I might try something along those lines at some point - using NR to drive it all of course :)

[Nicholas O'Leary]

Thanks Julian... We do get to have some fun. Comments are off for a reason... and you wouldn't be able to sign up if you tried :) not got around to updating the template to hide that gorp.

Nick

[Ra Wa]

My two cents worth on existing nodes that could be enhanced

Is it possible to add a one-shot option to the switch node so that a message is sent only the first time a condition is met?  I know you can chain a switch and a trigger node together to make something similar but the use-case of "something is out of range better tell a human about it"  is such a common one that it should be made a simple as possible.

If the change nodes "search and replace" mode could operate over arrays of strings as well as plain strings it could be more useful.

Extend the http request node to allow custom headers. Webservices like Xively require a key in the headers to authenticate.

[Nicholas O'Leary]

Hi Ra,

Dave was working on a report-by-exception node that could be used in various scenarios like you describe. I'm not sure adding it to the switch node makes sense - we are always cautious about overloading a single node with too much behaviour that is best served by separating it out.

The http request node does allow you to set custom headers... pass in msg.headers as an object of header-name:value pairs. I think the sidebar help mentions that... but I'm on my phone so can't easily check from here. We don't allow you to set headers in the node config itself, but that's just down to not having got around to the fiddly ui work to make that a nice experience.

Regards,
Nick

[Dave C-J]

The rbe node is here. https://www.npmjs.com/package/node-red-node-rbe
But the trigger node as mentioned is better for the once and once only use case (until reset).

[Luis Montes]

So, biggest improvement I'd like to see right now is build process for client side JS.

I understand that up to this point the MO has been to reduce friction for new users, but I think that's still possible.  An npm post install script calling gulp or grunt and webpack would be really easy to put in place.

Not only to reduce the current number of requests on startup, but to give third party module developers a way to safely package client side libraries and manage dependencies without polluting the global scope.

I've done the build process for other projects, and would more than happy to take a stab at it. 

[Julian Knight]

OK, I always had issues on my own blog with comments until I moved to using Disqus. Now I get very few issues, maybe 1 in 6 months. Also, there is a URL issue in your last post but I managed to find the talk online.
http://www.slideshare.net/tomcoates/webstock-2013-an-animating-spark

[Emil Oberg]

A bit of crossposting, but here's a small ping node I hacked together which hopefully will suit your needs:

https://www.npmjs.com/package/node-red-contrib-advanced-ping

Emil

Den tisdag 27 januari 2015 kl. 12:13:14 UTC+1 skrev Julian Knight:

Scott  made the mistake of asking so here it is! The "quick" list of thoughts for NR!

Just my view of course with only a few days working seriously with NR so they have probably all been covered in the past.

General Improvements

• Debug window to have pop-up window with pretty JSON output or at least a link to display it. Currently really hard to debug msg content, especially when it gets bigger & more complex.
  

• Search for object by code, e.g.: 3e610b62.c19ef4 - helpful when you have a node you forgot to name but that is reporting an error!
  
• Save debug output switches (without needing a Deploy) - I think I've seen another discussion about this.
  
• Send/Receive msgs to itself (e.g. event based flows without needing MQTT broker) - via WS, internal events? A good way to avoid the desire for while loops? And to keep areas of concern separated.
  

• Socket.IO instead of raw web sockets - specifically to enable secured sockets?
• Secure login to admin portal. Out of the box. Far too much of the IoT world is ignoring security!
  
• Move admin to /admin by default and present a default front page. Making it easier to present a full application for new Node-Redders.
  
• HTTPS by default (with default certs that need to be changed)
• Move remaining node templates to NPM - currently not clear which are which
• Easier external edit for Function and Template nodes - already discussed in the previous thread.
  Most likely a non-starter.
  

Ideas for New Nodes

• Time formatter - should be an easy one. Could use Moment.JS. Allow any allowed date/time format. Input field should be specifiable as should output field. Input should allow text. This is a really common transformation requirement!
• XML output - many web API's still demand XML.
  
• RSS output - shades of Yahoo! Pipes!! Possibly a nice way to collate and integrate many different
  
• A node to create/manage configuration nodes - save editing config files for static data
• Wrapper node - to keep node-sets together - with a title - cut/copy/move the wrapper keeps all the content together
  
• A "Dependency" node that doesn't trigger output until a set of inputs have been collected. This would allow an event to be triggered only after receiving several pieces of non-related or semi-related data (e.g. wait for 2 different web API's to return data before triggering output).

Specific Nodes that could be enhanced

• Better comment nodes - with HTML rich text - it is currently hard to document flows!
  

• Enable reordering of tests in Switch node - currently annoying when you started with a couple of entries plus an otherwise and then want to add something to the middle.
  
• More flexibility for JSON/XML nodes - ability to act on different parts (or whole) of msg
• MongoDB: Merge data into an existing entry - currently "update" seems to destroy any existing data so I currently have to have a node to read the existing data, combine the new data and then save the data.
  

• Ping that allows an external trigger. Also that allows multiple addresses - useful for checking if machines are alive. An ARP version of ping would also be very useful to enable checking if a SERVICE is alive on a device

Regards, Julian.

[Ra Wa]

@Dave
  The RBE node appears to be what I was thinking about.  Is there a catalog of additional nodes you can optionally install?  Even better would be some kind of link from the admin page that allowed you to browse and install modules. Searching the nodejs repo's gives an overwhelming number of results which are hard to refine

@Nicholas
  Thanks for the tip about msg headers, although its getting away from the goal of a nice point and click interface. Perhaps the existing node config GUI could have an "advanced" button that would expose more fields?

[Nicholas O'Leary]

Ra,

on the headers front - as I said, we haven't gotten around to the UI work yet. A number of nodes expose 'advanced' features via the incoming message - enable the users who know what they need to get the job done... sort out the point and click UI when we can. The sidebar info should detail what properties can be configured via the message.

As for making it easier to find nodes in npm... if module authors have followed our guidance, their package will be tagged with the 'node-red' keyword - this link then lists them: https://www.npmjs.com/browse/keyword/node-red

I had tried to embed that page on the node-red website as a quick way to aid discovery... but they prevent the page from being embedded in an iframe (wasn't aware of that http header before, and perhaps some browsers would ignore it... but certainly not chrome). For now, we link to it from the front page of our docs.

The intent is to be able to browse for node npm packages via the editor, and install from there, without having to restart. The underlying API is there to do it, but again, the hard work is getting the UI right.

Nick

--