Key features:

• Storage for inbound and outbound messages (SQLite)
• Chatbot user management and persisted chat context (SQLite)
• Admins management with multiple roles
• Basic Content Management System with custom fields
• Chatbot simulator
• GraphQL endpoint to access SQLite database
• New Node-RED nodes (MC GraphQL, MC Simulator, etc)
• Plugins repository for additional features
• Pluggable and open architecture
• Docker image

User Management

When enabled, the bot is persisting bot's user information (fist name, last name, language, chat context, etc) that can be inferred or extracted from the chat platforms. All users can be searched, modified or deleted from Mission Control (i.e. change user's detail or inspecting the current chat context).

Each new user receives a unique userId which can be used to identify the user within the chatbot indipendently from the chat platform (i.e. the same user can access the bot with multiple platforms, there's a 1-to-many relation between userId and chatId).

A custom JSON payload field can be used to store anything related to a user, it can be modified from Mission Control or - programmatically - using the MC GraphQL node in Node-RED.

Messages Storage

Messages are automatically stored in SQLite, it's now possible to inspect messages filtering for chatId, platform, userId or chatId.

Admins

Access can be granted to an unlimited number of admins with fine grain permissions.

Every feature has it own set of permissions that can be added individually to each admin.
The Mission Control's panel can handle multiple chatbots, admins can be assigned to all or specific chatbots.

Chatbot Simulator

It's now possible to simulate the bot with the chatbot simulator inside Mission Control, it's even possible to impersonate an existing user to investigate on production problems.

Implementing the simulator is easy, just drop the MC Simulator nodes in the flow like normal senders and receivers.

GraphQL support

SQLite database can be accessed with GraphQL: chabots can read/write data using MC GraphQL node, admins can read/write data using Mission Control's panel, third party systems can read/write data using the /graphql endpoint (with a security token).

These are the available entities

users chatbot's user
messages the inbound and outbound messages
content the post-like contents
records user-related entities (i.e. orders, invoices, etc)

Content Management System

It's a simple post-like content management system with some basic fields (i.e. title, body, category, language, etc) plus

slug it's an arbitrary id to identify a content. For example it's possible to fetch the content with MC Content node using the slug instead of the numeric id or it's possible to use it to identify the same content in different languages (multi-language support)
custom fields a list of structured and typed fields for a content (string, number, etc)
payload a custom JSON field that can contain anything
namespace contents are grouped by namespace, the default one is content, but it's possible to develop plugins using different namespaces and reusing the same UI, the Mission Control's CMS can be used to store anything

New Node-RED nodes

A bunch of new nodes are available to use the power of Mission Control:

MC Content to easily fetch content from Mission Control's CMS using the slug or the id
MC GraphQL to explore and persist data on SQLite using simple GraphQL queries
MC Simulator sender / receiver add these nodes to simple add support for the simulator in Mission Control
MC User Payload to store and persist any kind of json payload into the user's space in SQLite

Plugins

This is actually the most important feature. Mission Control has an open architecture and it's pluggable: every feature is a plugin, new and optional features can just be plugged into the control panel.

Some simple plugins are already available in the Plugins Store like Send Direct Message, Commands, Knowledge Base, Authorization and more to come in the future.

Since RedBot is open source, everyone can develop custom plugins using React and RSuite (docs for this is still not available).

Docker image

There's an official Docker image for RedBot, just run it to quickly test RedBot in a local environment or to easily deploy in production.

Just run (Mission Control is not enabled by default)

 docker run -d -p 1880:1880 \
   -e REDBOT_ENABLE_MISSION_CONTROL=true \
   guidone/redbot

Everything works fine until the moment we put everything in production and we secure the Node-RED server, the web socket connection remains pending. That's because the Web Socket connection is initiated through the http:// protocol (which requires authentication) and then upgraded to ws://.

I've found the solution after digging a little in the Node-RED code (since the lack of documentation on this topic)

import Sockette from 'sockette';
const ws = new Sockette(
  'http://localhost:1880/comms', // the Node-RED server  
  {
    // ...
    onopen: () => {
      const raw = localStorage.getItem('auth-tokens');
      let json;
      try {
        json = JSON.parse(raw)
      } catch(e) {
        // do nothing
      }
      if (json != null && !_.isEmpty(json.access_token)) {
        ws.send(`{"auth":"${json.access_token}"}`);
      }
    }
  }
);

Basically the trick is to use the same Node-RED authentication token to authenticate the web socket connection.

The 0.19.4 will use the Event API which has the drawback of being not compatible with the Express stack of Node-RED, for this reason the web hook server is running in a separate Express app on a different port (that can be configured in the connection panel).

Follow the updated instruction here to upgrade to the new connection params.

In order to create a SMS service you have to buy a Twilio phone number (any country is fine).

Twilio sends notification of incoming messages with a callback, use ngrok to expose your development instance of Node-RED to a public address, open a Terminal window and

ngrok http localhost:1880

You should get something like this

The address https://*.nkrok.io is the public URL that points back to your development machine.

First go to the Messaging services section and create a new service and pick up "Chatbot/Interactive 2-way" from the drop down menu.

Associate the Twilio number to this new service

Then check the "Process inbound message" and fill it using the ngrok address from the Terminal window, it should be something like

https://<my-ngrok-address>.ngrok.io/redbot/twilio

Now switch to RedBot and create a connection for the Twilio Sender node: the Accound SID and Auth Token will be requested, you'll find both in the Twilio's Dashboard

Also don't forget to fill the Sender Name (the Twilio number you bought in the first step).

To verify that everything is working fine, try a simple flow to send out an SMS

In the Conversation node set the chatId with the recipient's phone number (complete with the international prefix). Be sure that the international prefix of recipient phone number is included in the Geographic Permissions.

In RedBot there's the chat context, it's a volatile memory space where it's possible to store variables related to the current chat user, for example consider this flow in which we ask the user to type in his email.

The first Message node just sends out the question to the user "What is your email?" (always use a conversational tone with a chatbot and not cold robotic sentences like "Type your email").

Note that the Telegram Sender node has the track option enabled, that means that the chat flows will re-start from here: any answer from the chat user will be redirected to the output pin following the rest of the flow.

The Parse node analyze the incoming message and cab be configure to search for a pattern, it could be email, image, location, etc.
In that case it searches for a valid email: if the content of the incoming messages matches the pattern, the value is stored in the chat context and the output is redirected to the first output, otherwise the second output.

If the user's input doesn't match a valid email, a warning message is sent to the user and the flow restart from the node asking for the email.

If a valid email is found, it's stored in the chat context (the name of the variable can be configured in the Parse node panel) and it's available in the rest of the flow.

For example we can use it in the final Message node with a handlebars-like syntax with the text: "Thanks, from now on I'll use {{myemail}} as your email".

Or we can use it in a Function node:

// get the chat context
var chat = msg.chat();
// email payload
msg.to = chat.get('email');

To setup a Telegram bot, follow the tutorial.

A good habit is to inspect the chat bot log searching for user sentences that were not recognized by the bot and then update the parsers Listen node, RiveScript node, etc) in order to support it.

In RedBot every platform receiver can log the conversation to a file, it looks like

196520947 [Guido Bellomo] > Wed Oct 05 2016 12:08:45 GMT+0000 - /start
196520947 [Guido Bellomo] < Wed Oct 05 2016 12:08:45 GMT+0000 - Hi, this is GuidoneBot, here's what I can do for you:/help - you're already seeing this/where - tells where's Guido's house/cv - to get an updated CV (via email)/cam - pry into Guido's living room/message - send a high priority message to Guido/home - check if Guido is at home
196520947 [Guido Bellomo] > Wed Oct 05 2016 12:11:23 GMT+0000 - Come ti chiami?
196520947 [Guido Bellomo] > Wed Oct 05 2016 12:11:23 GMT+0000 - Sorry, I'm can only speak English

The first string is the chatId followed by the name (if available). Then the symbol > means it's an inbound message (from user to the chatbot).

There is also the Log node that produces a log string for every message that can be manipulated inside Node-RED (in case for example the log string should be sent to an external service).

I needed something simpler for my chatbot, a way to get fetch all current values from all sensors, something like this

{
  "temperature": 27.5,
  "co2": 246,
  "humidity": 60,
  "noise": 38,
  "pressure": 1009.5,
  "pressureTrend": "stable",
  "externalTemperature": 30,
  "externalHumidity": 51,
  "externalTemperatureTrend": "stable"
}

So I created this node-red-contrib-netatmo-dashboard.

To install

cd $HOME/.node-red
npm install node-red-contrib-netatmo-dashboard

See Netatmo Connect to get an API key.

First of all install Node-RED

sudo npm install -g node-red

Then open the user data directory $HOME/.node-red and install the package

cd $HOME/.node-red npm install node-red-contrib-chatbot

Then run

node-red

The next step is to create a chat bot, I recommend to use Telegram since the setup it's easier ( Telegram allows polling to receive messages, Facebook requires a https callback and a valid https certificate).
Telegram is really coherent and you have to use a chat bot to create a chatbot. Connect to @BotFather and type /newbot, then in the next two steps give the bot a name and username (this will be the real unique address of your chatbot), you'll get something like this for @my_new_chat_bot

Copy and paste the access token. For more information read here.

Then open your Node-RED and add a Telegram Receiver, in the configuration panel, add a new bot and paste the token

Now add a Message node and connect to the Telegram Receiver node

Finally add a Telegram Sender node, don't forget to select in the configuration panel the same bot of the Telegram Receiver node, this should be the final layout

Now you have a useful bot that answers "Hi there!" to any received message.

Receving the same answers is not very useful, we can introduce Command node: it will pass through the output only if the input message is "hi":

In this way it's possible to trigger different actions with different commands, read more about Telegram commands here.

RedBot is a Node-RED framework to create chatbots for Telegram, Facebook and Slack. Almost no coding skills required.

Node-RED is a tool for wiring together hardware devices, APIs and online services in new and interesting ways.

With RedBot it's possible to easily create chatbots just wiring together basic blocks like message, audio, location, etc. and interact with the Node-RED ecosystem. If you have particular need, you can do it by yourself in NodeJS, it's all open source!

RedBot is able to understand user's input using a simple token-based detector or more advanced language interaction like RiveScript.

The GitHub repository, a quick tutorial to setup a Telegram chat bot and some blog posts about chatbots.

app.get('/mypage', function(req,res,next) { 
  sequelize.search(query1)
    .on('success', function(res_query1) { 
      sequelize.search(query2)
        .on('success', function(res_query2) { 
          res.render('my_template', {
            query1: res_query1, query2: res_query2
           });
        });
    });   
});

There's nothing wrong with this, the only problem is that as long as the page gets new functionalities, you keep nesting queries and asyncronous callback.
The resulting code could become unreadable after few cycle of releases.

The app.get() accepts any combination of middlewares and arrays of middlewares, each one carrying the same instance of req object (that means we can use it to store temporary result...).
So we could split everything in middlewares using the rule of thumb that only the last middleware is allowed to speak with the rest of the world

app.get('/mypage', 
  function(req, res, next) { 
    sequelize.search(query1)
      .on('success', function(res_query1) {
        req.query1 = res_query1;
        return next();
      });
  },
  function(req,res,next) {
    sequelize.search(query2)
      .on('success', function(res_query2) { 
        req.query2 = res_query2;
        return next();
      });
  },
  function(req, res, next) { 
    res.render('my_template', {
      query1: req.query1,
      query2: req.query2
    });
  }
);

Basically every middleware performs a single step in our asynchronous operations, saving the result in the req object (used like a stack for temporary result) and, finally, calling return next(): don't forget this, it passes the control to the next middleware (otherwise the browser call will hang up until time out).

So far it's just a way of writing the same thing in a different manner. But suppose that, at some point, you want to be able to update the first query via AJAX without reloading the whole page.
We don't want for replicate piece of codes, so we just assign the first two middlewares to variables (for example mw_1 and mw_2) and detach the part of the template that renders query1 into a sub-template (called within my_template).
After this code reorganization, it's super easy

app.get('/mypage/ajax', mw_1, function(req, res, next) {
  res.render('my_subtemplate', { query1: req.query1 });
});

The front-end code (not relevant for this example) just have to put the resulting piece of HTML in the right place.
We added functionality without duplicating functionality and without messing up the organization of the code.
Welcome middlewares!

It's pretty simple: just configure any number of intervals, a callback in case of success, a callback in case of failure, and the function that checks the server

var poller = new Poller();
poller.intervals([1000,5000,10000])
  .checkback(function(callback) {
    // could be anything asynchronous
    $.getJSON('/is/server/ready', function(response) {
      if (response.ready) {
        callback(true);
      } else { 
        callback(false);
      }
    })
    .callback(function() {
      // checkback succeded and the end of one interval
      // stops the poller and callback
      console.log('Ok')
    })
    .failback(function() {
      // after the third attempt, exits calling the failback
      console.log('Failed');
    })
    .start(); // start the process

Each callback(), failback(), checkback() run in the Poller context, means that this operator points to the Poller instance.
A bunch of additional methods are available like: start(), stop(), restart(), next().

To do: implement Deferred pattern for the method that checks the server

Update: Update with a GitHub repository and support for deferred/promise.