[ANNOUNCE] node-red-contrib-sse-client


Hi folks,

A couple of weeks ago there was a topic on this forum about listening to an SSE stream (Server Sent Events). Seemed that there was no real SSE client available in Node-Red, so I decided to create node-red-contrib-sse-client.

Will publish it to NPM in a couple of days. Until then it can be installed directly from my Github account:
npm install bartbutenaers/node-red-contrib-sse-client

All ‘constructive’ feedback is more than welcome !

P.S. I have a minor CSS issue. My config screen contains two tables (‘events’ and ‘http headers’), both having the same minimum heigth:

I hoped that both tables would get the same height, however the screenshot shows that the last table has more heigth. Does somebody know how this can be accomplished ?

Kind regards,
Bart Butenaers

Server Sent Events listener

@BartButenaers - I tried instalng this in the NR running on my Mac and it does not show up in the sidebar.

Is there something I’m missing?


Tiny comments. The label Url should probably be URL to be consistent. And the prompt Enter URL would be better with a small example. I don’t know SSE so is the URL local? Have a standard pattern ? Have a default?


Hi Paul (@zenofmud), I have uninstalled it on my Raspberry and installed it again but no problems here …


When you install a node directly from Github, you should refresh your browser window. Otherwise the installed node doesn’t appear in the sidebar. Could that be the problem ??

Hi Dave (@dceejay), the code on Github is updated with your feedback (uppercase label, placeholder “http://”, and same validation like in the httprequest node):


P.S. the URL can be any SSE server (local or not), like e.g. the SSE demo stream on my readme page. So I cannot add a default URL.


Hi. Didn’t mean you to add it as the (active) default, but you could make the prompt say. " URL e.g. http://your.server.com"


Ok, I uninstalled and installed it and now I see it - it could be that I was looking in the wrong place…

The layout is even for me on the mac in Safari, Chrome and FireFox:

(Bear with me since this is the first time I’ve heard of SSE) Why the two options when you press ‘+’ in the HTTP headers?
looking at the code is the first the header name and the second the header value? It is not clear to me. Maybe putting a default in both and expanding the explanation would be useful or if the header name is a set possibility, why not make that a pulldown list with all the possibilities.

Just some observations


Hi guys,

I must admit that the new version on Github has become a bit more self-explaining:


@zenofmud: the list of possible http header fields is rather large, so not really useful to show them in a dropdown. Instead I have added now a link in the node’s info help:



I looks much nicer now!


Hi folks,

I have published this morning version 0.0.1 to NPM. You can find it here on NPM.

For some reason you cannot find it by searching on NPM, and it is also not visible on flows.nodered.org. Hopefully this is related to the issue that Nick has reported on NPM, and hopefully it will be fixed soon ...



FYI : Just released version 0.1.0 which allows the URL and Http headers to be set in the input message (when not specified in the config screen).


Looks interesting - what is SSE typically used for ? Are there some useful publicSSE servers out there?


I haven't really used it myself, just developed that node to help some poor souls on this forum...

It is used for clients that want to be notified automatically by a server, for changes that occur on that server. So the clients don't need to poll every X seconds, to ask the server for new changes.

For example your Node-RED editor shows all flow changes of the server (node status updates...). The main difference is that the flow editor uses websockets to implement this. Websockets is a bit similar to SSE, but there are some major differences.


SSE is very useful and under utilised in my opinion. In essence, events are pushed to the client JavaScript. In particular, your JavaScript doesn't have to perform any connection management as the browser takes care of this for you. This, along with a little more structure than WebSockets, is the major selling point.

BTW: Thanks for providing the node! I noticed a small issue where I was unable to use a mustache template declaration in the URL. I got around the issue by constructing the msg.url as an input, but I thought you'd like to know.


Hi Christopher,

Thanks for yor feedback! Indeed I don't support Mustache yet. Will add it when I have time. Have to write it down somewhere, otherwise I'm going to forget it :wink:




I have published version 0.2.0 on NPM, which allows the URL to contain the Mustache syntax. Information has been added both in the Info panel and on the Readme page. Please let me know if you have any issues with it...

Have fun!


Wow, thank you so much!