Category: XDK

Debug Node js remotely on Intel Edison with Jetbrains Idea

This blog post will demonstrate how to configure Jetbrains Idea (or similar product) to remotely debug Node js applications on an Intel Edison. Though I will use Edison for this post these instructions should work for remotely debugging most Linux targets running Node.

I’m a big fan of using Node js to power my IoT applications on the Intel Edison. It has a lot of advantages — ease of use (once you get used to the node way of doing things), support for mraa and upm,  and it is pre-installed. Intel even provides a decent ide to code it with – the XDK for IoT.

Jetbrains makes several ide products for various languages. Most will support HTML5 and Node js via a plugin. I find Jetbrains tools are fairly reasonably priced and more than pay for themselves in productivity gains vs other tools. (No, I don’t work for Jetbrains, I’m just a fan). For the remainder of this post when I refer to one of Jetbrains compatible products I’ll refer to it as JB.

The XDK for IoT is a fine tool, but Jetbrains’ tools are an order of magnitude better. With Intellij I get better HTML5 support, Javascript debugging and Node debugging right in the ide. I prefer the Jetbrains ide for the bulk of the coding I do.

To use JB we need to do a little configuring. First – make sure the Node js plugin  is installed.  Jetbrains has detailed instructions on installing plugins on their website.  You should go ahead and install the “Remote Host Access” plugin too — we will need that to transfer files later.

We will be using a ssh tunnel to forward our host Node debugger port (default 5858) to our Edison device. We have a choice of ports to use so we have the option of working with more than one Edison. We will use port 5858 on one Edison in this example.

So — to configure:

On the Edison:

Allow port forwarding: 

SSH by default does not allow remote hosts to forward ports so we need to enable it. Edit /etc/ssh/sshd_config and find the following line somewhere in that config file.

#GatewayPorts no

Change it to this:

GatewayPorts yes

Shutdown the app running in .node_app_slot. 

I generally start my IoT apps from one of the templates included with the XDK (I’m lazy that way). I will also go ahead and use the node_app_slot directory to upload it to. This keeps the apps XDK compatible. I then open the local project directory in JB and setup the configuration for the project.

The problem here is that the Edison will autostart the project on a reboot. This makes us have to take the extra step of starting up the XDK, connecting to the Edison and stopping the running project.

Reboot the Edison to ensure the changes to our files are picked up. If you have code in node_app_slot go ahead and stop it.

On our host machine:

Setup ssh tunnel for port 5858:

The magic that makes our remote debugging work is ssh port forwarding. For Windows users this can be set up with Putty as described here. Just skip to the Putty config part and ignore the rest.  For Linux and Mac users this should work:

ssh -f root@edison.local -L 5858:localhost:5858 -N

Where edison.local is your device mdns name or ip address. This starts the port forwarding session. We have to manage this manually. If we reboot our Edison we need to kill the current ssh tunnel connection and start a new one. To do this first run:

ps aux | grep ssh 

This will list all the currently running ssh process. We need to find the one that matches the signature of the tunnel. It is easy to spot — the output will be look like this:

This is the output of ps aux | grep ssh showing our ssh processes.

From the output we can see the process that matches our ssh tunnel. The process id is the first number from the right (on Mac any way) and is 8084 in this case. To end the connection we need to kill the process with this command:

kill 8084

Windows users will just close Putty. This connection will also be cleared after a reboot.

Create a remote Node debug configuration in JB:

This assumes you already have a project started. What I normally do is start the project using a template in XDK and then open it with JB. This keeps the code compatible with both applications.

In JB select Run/Edit Configurations. We will click the + button and select ‘Node.js Remote Debug’. Name it what ever you like and set it up like this:

Node-js-deployment

When we debug this app we will use this configuration. There is more info on setting up Node js configurations here.

Setup Deployment in JB:

JB will automatically upload our source files to the Edison via a deployment configuration. To access this Select ‘Tools/Deployment/Configuration’ from the JB menu. Click the + button in the upper left and create a configuration that looks something like this:

deployment-1-node-jb

To keep from uploading unwanted files setup some exclude paths (these are local paths):

deploy-exclude-node-jb

To enable autoupload select ‘Tools/Deployment/Automatic Upload (always).  Whenever we save a file in our project it will be automatically sent to the proper location on the Edison. More info on JB deployment settings can be found here.

Once we have the deployment setup, we upload everything to the Edison by selecting “Tools/Deployment/Upload to xxxxx”.  Select the option that works for you.

Now that we have everything configured we are ready to debug. To start the debugging session we first ssh to the Edison and start our app in debug mode like this:

node --debug-brk app.js

Where app.js is the file we want to debug. This will cause node to start up and pause. We then select “Run/Debug” from the JB menu and give the debugger a little while to connect to our target machine.

Then we simply debug and run the app with all the Jetbrains goodness.

References:

https://www.jetbrains.com/idea/help/running-and-debugging-node-js.html

http://stackoverflow.com/questions/8445534/how-to-remote-debug-node-js-with-phpstorm

http://blog.trackets.com/2014/05/17/ssh-tunnel-local-and-remote-port-forwarding-explained-with-examples.html

Implementing the MICS-VZ-89T gas sensor on Intel Edison i2c

On my current project I have the requirement to monitor indoor air quality. What is of interest are the levels of Volatile Organic Compounds (VOCs) and CO2.  There are specific thresholds that we are looking for that when exceeded should trigger an action. For VOCs it is when the concentration is greater that 0.9 ppm. For CO2 it is when the concentration is 1000 ppm above ambient out side C02 — which is generally around 400 ppm. The links above out line the dangers of these indoor pollutants. When the threshold is reached we want to start the ventilation system and optionally message a user.

When I need a sensor my first choice is to find one that implements i2c. In this case I found a good candidate for the job in the SGX Sensortech MICS-VZ-89T. The VZ89 product is a small board with a MICS SMD device integrated with an i2c controller. The board comes in both 5 volt (VZ89) and 3.3 volt (VZ89T) versions that are are easy to implement using a logic level shifter with the Edison on a mini breakout board. (For an example of using a logic level shifter you can see my article Intel Edison and I2C sensors with XDK.)

There was no driver that I could find for implementing the board with my setup so I had to roll my own. This wasn’t too hard, but I did have to break out the logic analyzer to get it right. If we examine the MICS-VZ-89T I2C Specification page  we see that the device only has two commands. These are Set ppmC02 and Get VZ89 Status. According to the MICS-VZ-89T Data Sheet the device comes calibrated from the factory so we don’t need to implement Set ppmC02. That leaves us Get VZ89 Status. The code that follows here is available in an XDK project on git hub.

To read the status we have to perform a two step process. First we write a command byte of 0x09 to register address 0x70. We follow this by writing two data bytes to the same register. I write 0x00 twice.

We then read 6 bytes immediately after writing the command byte. The bytes are decoded as follows:

Data byte 1 = CO2-equivalent value. 
Data byte 2 = VOC_SHORT value. 
Data byte 3 = VOC_LONG value 
Data byte 4 = Raw sensor 1st byte (LSB). 
Data byte 5 = Raw sensor 2nd byte 
Data byte 6 = Raw sensor 3rd byte (MSB).

To implement the functionality I created the following class in a node module:

//Import mraa 
var mraa = require('mraa');

//Constructor -- set defaults and populate tx_buf
function VZ89(bus , address){

 this.bus = new mraa.I2c(bus || 1); 
 this.bus.address(address || 0x70); 
 
 this.tx_buf = new Buffer(3); 
 this.tx_buf[0] = 0x09;
 this.tx_buf[1] = 0x00;
 this.tx_buf[2] = 0x00; 
 
}

//Add a function to get the device readings. 
VZ89.prototype.getReadings = function() {
 this.bus.frequency(mraa.I2C_STD);
 this.bus.write(this.tx_buf); 
 return this.bus.read(6);
 
};
//Export as a node module 
module.exports = VZ89;

The MRAA library is used to access the i2c bus, so it is imported at the top or the file. There is a constructor that optionally takes a bus number and a devices address. The VZ89 is addressed at 0x70 so we don’t really need to change that. If the Edison mini-breakout is used we have a choice of busses. I have set this to bus 6 as I am using the Edison Arduino for this example.

A class function is added to implement named getReadings to perform the measurements and return data from the device. In this case the buffer is passed back to the calling program for use.

To use the class the code in the server file would look like this:

//Import our sensor file from the file system
var Sensor = require('./VZ89.js'); 
//Create an instance of the sensor object. 
var sensor = new Sensor();
//Create a var for the receive buffer.
var rx_buf; 

//Call the readBuf function every minute. 
setInterval(readBuf , 60000); 

//A function to read the sensor data, perform data conversions and display on the console every minute.
function readBuf(){

    rx_buf = sensor.getReadings();
 
    console.log("Co2_equ: " + ((rx_buf[0] - 13) * (1600/229) + 400) + " ppm"); 
    console.log("VOC_short: " + (rx_buf[1])); 
    console.log("tVOC: " + (rx_buf[2] * (1000/229)) + " ppb"); 
    console.log("Resistor Value: " + 10 * (rx_buf[3] + (256 * rx_buf[4]) + (65536 * rx_buf[5])) + " ohms"); 
}

The details of converting the rx_buf data to usable values are in the data sheet.  The ones we are most interested in are Co2 equivalent (rx_buf[0]) and total VOC (rx_buf[2]).

As you can see, the MICS-VZ89T is a pretty easy to use device once you know how. There are only a couple of gotchas to be aware of. First, the device can only be polled once a second. I find if I try to get the readings faster than that the device will return nulls. Secondly, care must be taken when handling the device. It contains organic material that is susceptible to solvents.