Change MQTT keepalive value

[Juan Sancho]

I'd like to modify the default keepalive value of the MQTT subscription node, which is set by default to 15 as seen in:

/usr/lib/node_modules/node-red/nodes/core/io/lib/mqttConnectionPool.js

[...]
var options = {keepalive:15};
[...]

Could somebody explain a bit how to properly create a need field in the MQTT IN dialog box to update this parameter?

Thanks.

[Juan Sancho]

Not a single response? :-(

[Julian Knight]

As this is a core node, it really needs Nick or Dave to respond. A possible enhancement to store the keepalive value in the configuration node?

[Nicholas O'Leary]

HI Juan,

apologies for missing your original mail.

There is a piece of work going on to refactor the MQTT node - https://groups.google.com/forum/#!topic/node-red/DrUaSN9Mu0Q - we should make sure that takes into account the requirement to set the keepalive value.

In the meantime, if you want to learn how to add to a node's properties, the documentation is here: http://nodered.org/docs/creating-nodes/properties.html. Rather than add it to the MQTT In node, as Julian says, it would belong in the mqtt-broker configuration node.

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.

[Dave C-J]

right now the keepalive option is not surfaced upwards enough to be visible at the node layer (ie the .js and .html files can't affect it). While the above work is happening the hack would be to hand edit line 52 of mqtt.js in nodes/core/io/lib/ to change the default as you wish.

[Juan Sancho]

I'm aware the keepalive option is not surfaced upwards enough, I've tried to do so but failed :-/ For the time being, I can just modify the file by hand, and then follow the link Nicholas point out.

Thanks for your effort.

[Richard Ruston]

It would be easy enough to surface the keepalive interval in the new version of the node I hope to submit (soon). The only question would be exactly how to do this without adding too much clutter to the config panel.

If it's ok to just add a field to the main panel, I can do that pretty much right away - if we want to hide it behind some kind of 'Advanced' section or in some other way, I'll probably leave it for a further iteration as I'd like to get the core changes submitted.

Cheers

R

[Julian Knight]

It could go after the Client ID, aligned as for the Broker/Port fields above it? Otherwise 1 more line isn't too bad surely? It isn't a complex config panel.

[Richard Ruston]

As part of the update, I've added two additional check boxes with descriptions to the default panel, and a third becomes visible depending on the setting of one of those two, so the panel is starting to look pretty full. There is also the potential follow up work to add support for client certificates and non-trusted CA certificates, which will require more config options.

Given that, and that the main driver for the update was to get SSL connections working, I'd like to get the initial pull request submitted without surfacing the keep alive interval. Once people have had a chance to see the changes introduced by the new node (assuming the pull request is accepted) , it might well influence discussion on how these 'advanced' options are presented to the user.

Cheers,

Richard

[Juan Sancho]

Hi,

I just want to explain why I need to increase the Keepalive value, as might be useful for someone else.

Imagine a flow in which you request a resource using the HTTP Request node, and that request takes too much time. In fact, more than 15 seconds, which is the default value for the Keepalive parameter of the MQTT Subscribe node. Then, what is happening is that Node-RED fails to send the internal Keepalive message to the MQTT Broker, so the client gets disconnected. After a certain amount of time (15000 milliseconds by default), the MQTT client tries to reconnect, by the way.

Cheers,
Juan

[Nicholas O'Leary]

Juan, the MQTT client should be sending pings in the background to keep the connection alive. It is not dependant on you publishing a message every 15 seconds to keep the connection alive.

I'd be interested to understand more about the HTTP Request you're making - is it the size of the response that causes the delay, or is it a slow response from the server? Either way, node's event model means the MQTT node should not be blocked whilst the request is in process.

Nick

--

[Juan Sancho]

Hi Nicholas,

Juan, the MQTT client should be sending pings in the background to keep the connection alive. It is not dependant on you publishing a message every 15 seconds to keep the connection alive.

Of course not, imagine if that was the case :-p

 

I'd be interested to understand more about the HTTP Request you're making - is it the size of the response that causes the delay, or is it a slow response from the server? Either way, node's event model means the MQTT node should not be blocked whilst the request is in process.

The size of the response is the one that causes de delay. Tested. This is the resource (http://informo.munimadrid.es/informo/tmadrid/pm.xml), 1.4 megabytes. And here the flow in case you'd like to test it:

[{"id":"50ef7066.cf7268","type":"mqtt-broker","broker":"localhost","port":"1883","clientid":""},{"id":"a4683606.f2d608","type":"http request","name":"Get traffic status from Madrid","method":"GET","ret":"txt","url":"http://informo.munimadrid.es/informo/tmadrid/pm.xml","x":327,"y":144,"z":"13c06d4d.c42c8b","wires":[["33afc2c9.674a5e"]]},{"id":"33afc2c9.674a5e","type":"xml","name":"xml2json","attr":"$","chr":"_","x":325,"y":220,"z":"13c06d4d.c42c8b","wires":[["a5a65a8d.ae06d"]]},{"id":"f1965d1f.692ba8","type":"inject","name":"Every 5 minutes","topic":"","payload":"","payloadType":"none","repeat":"300","crontab":"","once":true,"x":333,"y":74,"z":"13c06d4d.c42c8b","wires":[["a4683606.f2d608"]]},{"id":"a5a65a8d.ae06d","type":"mqtt out","name":"MQTT Publisher","topic":"someTopic","qos":"0","retain":"false","broker":"50ef7066.cf7268","x":328,"y":293,"z":"13c06d4d.c42c8b","wires":[]}]