Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Input node feature definitions

zobalogh edited this page Oct 30, 2014 · 8 revisions

This page defines the features and design conventions that each input node should adhere to. The page is currently under development and changes to its contents are possible. Once the behaviour is agreed upon, these conventions are going to be migrated onto the Node-RED website for easy reference. Only the website reference should be used as a blueprint.

Input nodes MUST:

  • Create a new msg JavaScript object for every distinctive output they wish to generate. This is to be achieved for example by:
node.on("input", function(msg) { msg = {}; doSomethingWithMsg(node, msg); }); * It is essential for msg to be an object, otherwise it cannot be extended with additional fields in further nodes

Input nodes SHOULD:

  • Have clearly defined behaviour that triggers new msg objects to be sent upon meeting clearly defined conditions

  • If a condition forces the node to send multiple messages, they should all be individual msg objects rather than arrays of information

  • Clean up their state upon close node.on("close", function() {}

  • Report errors using node.warn() or node.error() if the external systems they're accessing are in an unknown/error state

Input nodes COULD:

  • Poll at regular intervals to see if msg trigger conditions are met:
node.interval = setInterval(function() { node.emit("input", {}); }, REPEAT_IN_MILLIS); * Alternatively they could fire by being triggered by callbacks => TODO define behaviour here * Reserve the right not to send anything at all, ever if conditions are never met

Clone this wiki locally

Morty Proxy This is a proxified and sanitized view of the page, visit original site.