• MQTT on Tessel

    Wednesday, September 24, 2014

    9/24/2014– Jon McKay

    Using MQTT on Tessel

    MQTT is a lightweight publish/subscribe protocol designed for machine to machine communication. The architecture features one central server that manages the subscriptions and publications from each of its numerous clients. Clients can publish data without having to be aware of who is subscribed (much like Node’s EventEmitter class).

    source: Eurotech

    MQTT is also designed to require minimum protocol overhead for each packet in order to preserve bandwidth for resource-constrained embedded devices. It’s a really simple framework for managing mesh networks of TCP-enabled devices.

    Tessel-MQTT Compatibility Backstory

    As far as I could tell, there is only one MQTT implementation in Node (surprising, right?!) and it’s really well maintained. Up until a few weeks ago, the library couldn’t run on Tessel due to a couple of Node and JS incompatibility issues. The biggest problem was the use of Function constructors, used primarily for speed improvements, which isn’t supported on Tessel yet.

    In JavaScript, the Function constructor accepts a string of JavaScript code which it processes into an actual function:

    var f = new Function(foo, bar, “console.log(‘the arguments are’, foo, bar)”);
    f(‘a trivial’, ‘example’); // prints ‘the arguments are a trivial example'

    It’s often used as a faster way to template a function, replacing Function.prototype.bind which runs abnormally slow on V8.

    Tessel’s runtime translates JavaScript to Lua on a host PC before being pushed to Tessel and run on a Lua Virtual Machine. We’ll need to push compilation functionality over to Tessel before Function constructors (or eval) can work on the device. Tim has made stready progress on a compiler written in C (as opposed to JavaScript) that will reside on Tessel itself and compile JavaScript to LuaJIT bytecode. But it isn’t quite ready yet, so we looked for another way around the issue.

    Matteo Collina, one of the primary maintainers of the MQTT.js library, and I started a discussion about the MQTT library’s compatibility with Tessel. He was kind enough to accept a pull request that replaced the Function constructors so that we wouldn’t have to wait for the C-based compiler to be complete to use MQTT on Tessel. I just had to fix one more issue with Buffer parsing and the library worked without a hitch on Tessel!

    Code Example

    Tessel can act as either an MQTT server or a client, and the client code is impressively simple in practice. In this code snippet, I publish the current temperature to an MQTT server every five seconds:

    var mqtt = require('mqtt')
      , host = ''
      , port = 1883
      , client = mqtt.createClient(port, host, {keepalive: 10000})
      , tessel = require('tessel')
      , climate = require('climate-si7020').use(tessel.port['A']);
    climate.on('ready', function ready() {
      console.log('climate ready');
      setInterval(function() {
        climate.readTemperature(function(err, temperature) {
          if (!err) {
           // You can only publish strings
            client.publish('temperature', temperature.toString());
      }, 5000);

    You can find the entire example on this Github Gist.

    If you have a project that requires the use of multiple data gathering clients interacting through a single server, consider trying out MQTT because it’s one of the simplest protocols for M2M communications.


    #mqtt #js #javascript #node #tessel #technical machine #temperature #home automation #climate #jon #mckay #matteo #collina #mqtt.js #node.js

  • How-to: Adding Buttons to Tessel

    Wednesday, September 24, 2014

    9/24/2014– Kelsey Breseman

    A number of users have requested a button module on Tessel. We welcome this and other module suggestions here, but in the meanwhile, I thought you’d find a tutorial on adding your own buttons (of any size and shape) useful.

    I’ve put this up on the Projects Page, so I encourage you to also check it out, access the repo, and comment there!

    But as long as I’m going into the details of how buttons work, I thought you all might appreciate it on the blog.

    Quick start: I just want a button.

    Your button should have two wires sticking out of it. Plug in one side to ground, and the other to pin G3.


    npm install tessel-gpio-button


    var tessel = require('tessel');
    var buttonLib = require('tessel-gpio-button');
    var myButton = buttonLib.use(tessel.port['GPIO'].pin['G3']);
    var i = 0;
    myButton.on('ready', function () {
      myButton.on('press', function () {
        console.log('Press', i);

    Congratulations, you now have a button!

    How it works, and why

    Why add a button over the GPIO?

    Buttons are a nice, easy way to make your project interactive. Tessel comes with API access to the Config button on the board. For many use cases, this is enough. But perhaps you want more buttons, or buttons with a certain look or feel. That’s where this tutorial will come in handy.

    What is a button, in terms of circuits?

    Electrically, a button is nothing more than a switch. One wire goes into the button; one wire comes out. When the button is pressed, the wires are connected. When not pressed, the wires are not connected.

    Making a button talk to Tessel

    Tessel communicates over 3.3V. That means that its pins operate between 0V and 3.3V. For a digital pin, 3.3V evaluates to “high” or 1 (truthy), and 0V evaluates to “low” or 0 (falsy).

    Tessel has six digital pins along the GPIO bank, marked G1-G6. Each of these pins is pulled high (3.3V) by default. In order to change the state of these pins from high to low, all you have to do is connect a digital pin to ground (GND).

    If you have a wire, you can try it out– plug in a wire (ideally black, for ground) in to the GND pin on Tessel’s GPIO bank. While running the code below, try sticking the other end of the wire into G3:

    // tutorial/polling-read.js
    // Read Tessel's GPIO pin G3 every 100ms
    var tessel = require('tessel');
    var myPin = tessel.port['GPIO'].pin['G3'];
    setInterval(function readPin () {
    }, 100);

    You should see a stream of ones while the wire is not plugged in, and a stream of zeroes when it is plugged in.

    Okay, now let’s try it with a button. It’s basically the same thing. Unplug your Tessel (it’s bad practice to mess around with wires while your Tessel is powered). Your button should have two wires sticking out of it. One of them should plug into GND; the other into pin G3.

    Run the same code, and try pressing the button. You should see zeroes when the button is pressed, and ones when the button is not pressed.

    Button events

    Tessel has events for its pins. It fires an event each for rise, fall, and change.

    Since the signal falls to low when the button is pressed, and rises to high when the button is released, it seems like you should be able to just use pin.on(fall, function () {}). Let’s try it and see what happens:

    // tutorial/simple-event.js
    // Logs a message each time the pin falls
    var tessel = require('tessel');
    var button = tessel.port['GPIO'].pin['G3'];
    var i = 0
    button.on('fall', function buttonPress () {
      console.log('You pressed the button!', i);

    If you have a really nice button, this might just work. However, if you have a cheap button like mine, the fall event will be emitted more than once per button press. This is because you are dealing with a mechanical system, and the electrical contact is actually bouncing a little bit on contact and messing up the signal. You can read about this phenomenon here.

    In order to correct this problem, we need to do some software debouncing.

    Debouncing can be a very complicated problem if you need the ability to read the button several times a second (read a few approaches here). However, for most applications, you can simply reduce the rate at which your events can fire.

    Let’s try adding a delay timer to the event:

    // tutorial/debounced-event.js
    // Logs a message at button presses that are sufficiently spaced
    var tessel = require('tessel');
    var button = tessel.port['GPIO'].pin['G3'];
    var delay = 500; // Let's try every 500ms
    var ready = true;
    var i = 0
    button.on('fall', function () {
      if(ready) {
    function buttonPress () {
      console.log('You pressed the button!', i);
      // Set a delay timer
      ready = false;
      setTimeout(function () {
        ready = true;
      }, delay);

    500ms worked well for my button, but feel free to adjust the delay and see how long it takes for your button to stop bouncing.

    Wrapping the events

    For the sake of consistency, I’ve set up index.js of this folder the same way we set up every module, to emit an event on press. press and release are individually easy, but harder to have both due to our simple debouncing method. I’ve left that as an exercise for the reader (PRs welcome).

    Here’s some example code requiring index (or just npm install tessel-gpio-button):

    // examples/button.js
    // Count button presses
    var tessel = require('tessel');
    var buttonLib = require('tessel-gpio-button');
    var myButton = buttonLib.use(tessel.port['GPIO'].pin['G3']);
    var i = 0;
    myButton.on('ready', function () {
      myButton.on('press', function () {
        console.log('Press', i);

    Multiple buttons

    Say you want more than one button. Maybe you’re making a game controller, or a musical instrument or something. So you have several buttons to connect.

    All you have to do is connect one side of each to ground, and the other side to a different digital pin.

    Then make different instances for each button. Like this:

    // examples/two-buttons.js
    // Log button presses from two different buttons
    var tessel = require('tessel');
    var buttonLib = require('tessel-gpio-button');
    var button1 = buttonLib.use(tessel.port['GPIO'].pin['G3']);
    var button2 = buttonLib.use(tessel.port['GPIO'].pin['G2']);
    button1.on('press', function () {
      console.log('Pressing button 1.');
    button2.on('press', function () {
      console.log('Pressing button 2.');

    Pressing the different buttons will give you different messages.

    Note that I used a breadboard to connect several buttons to the same ground. If you’re interested/want to know more about breadboards, this is a really good place to start.

    That’s all! Enjoy.

    I’ll keep this tutorial up to date on its projects page

    #tessel #button #kelsey breseman #tutorial #how-to #electrical engineering #electronics

  • How Tessel Works: The Basics

    Tuesday, September 23, 2014

    9/23/2014– Kelsey Breseman

    Ever since Jon pushed out the Contribution Guide, I’ve been meaning to distill some of it into a more digestible format. It’s the basics of how Tessel works, hardware and software.

    This is an overview, not a complete picture– I recommend that you check out the docs and the full contribution guide if your interest is piqued.

    Rolls up sleeves.

    Okay, here’s how it works:


    Let’s dig into the software first. This software is designed to work on Tessel’s specific hardware, but we’re working on making it portable to other platforms as well.

    The basic interaction with Tessel is this:

    1. In the command line, you enter tessel run <file.js>.
    2. From here, the CLI bundles all of the files except those blacklisted in the hardware section of your package.json. If there is no package.json or node_modules folder, Tessel will bundle only the specified file.
    3. We then pass all the files found through Colony, our JS to Lua compiler.The CLI creates a tarball and sends it off to Tessel’s firmware via USB.
    4. The firmware receives the tarball, puts it in RAM*, and loads the script into the Lua VM in Tessel runtime. *or Flash, if you use tessel push instead of tessel run. We’ll go into that in the hardware section.
    5. The runtime environment takes over and defines all the global functions and node modules that the Lua code called into.
    6. When hardware-specific tasks are called by the Lua code, runtime makes calls into the appropriate C functions.
    7. When the process completes, runtime is shut down and the script is freed from memory.
    8. After the initial script runs and sets up event callbacks, the runtime waits for events. When an event occurs, the processor wakes up, runs the callback, and then goes back to sleep.
    9. When no event sources are waiting for events, or when you call process.exit(), runtime is shut down.

    To separate this out by components instead of chronology, there are four basic parts of Tessel’s software:

    CLI: Command line interface for interacting with Tessel over USB (repo: https://github.com/tessel/cli)

    Colony: JavaScript to Lua compiler (bundle installed with the CLI) (repo: https://github.com/tessel/colony-compiler)

    Runtime: Lua VM running the interpreted code. The runtime layer also includes the compatibility layer for core JS functions (such as String and Number) and core Node function (such as fs and buffers). (repo: https://github.com/tessel/runtime)

    Firmware: C code interfacing the Lua runtime with all of the hardware components (Wifi, RAM, Flash, SPI/UART/I2C busses). The firmware layer also handles interrupts. (repo: https://github.com/tessel/firmware)

    All right, that’s the software basics. There are more details overall and for each subsystem on our contribution guide (https://github.com/tessel/contribution-guide), so for the sake of brevity I’ll let you investigate on your own. Let’s move on to Tessel’s hardware.


    At its core, Tessel runs a 180MHz ARM Cortex-M3 LPC1830. The M3 was chosen as the smallest available chip with the capacity to support external Flash and RAM. Tessel’s Wifi chip is the TI CC3000. There was a lot of excitement about this chip at the time of prototyping, and it was chosen as a good balance between cheap and easy to integrate into a system.

    Since Tessel was designed to be intuitive and familiar to web programmers, we needed a bit more memory to play around with than, say, an Arduino. So we have 32 Megabytes each of Flash and SDRAM. (For comparison, Arduino Uno has 32 Kilobytes of Flash, and 2 Kilobytes of SRAM.)

    Tessel’s firmware and runtime (compiled into the firmware) are stored in Flash memory. Current firmware takes up about 1.3MB, but the boot and firmware partitions reserve 2MB of memory just in case– leaving you 30MB to use for your own files.

    Tessel’s CLI gives you the option to either push or run any given JS file. When you run, code is temporarily stored in RAM and is not persistent across hardware resets; if Tessel loses power, you will need to re-run the code. This is designed for quickly testing code in development.

    If you push, the files are saved to Flash memory and run every time Tessel boots up– so if you want to plug Tessel into a battery, you’ll need to tessel push, disconnect, and plug the battery in. This is designed for deployment. You can read more about push vs. run here.

    The primary interaction for Tessel takes place through the four module ports. Each can be used to communicate with devices using SPI, I2C, and/or three digital GPIO pins. Ports A, B, and D also include UART, another communication interface.

    Module ports are designed for hardware modularity; currently we have fourteen single-function modules (BLE, servo, accelerometer, etc.) that you can swap into (almost) any of these ports. Drivers and APIs are npm installed with the package name written on the silk screen on the module. These modules are also all OSS/OSHW. You can find third-party design guidelines and module design philosophy here.

    There’s also a GPIO bank on the board designed to make it easy to interface with other hardware, or anything not available in module form. All of Tessel’s input and output signaling is 3.3V maximum voltage.

    You can power Tessel through its microUSB port (5V USB sources only), or through a pair of solderable pins on the board. Please read the guide on powering Tessel before you use these, though.

    You can find links to all of Tessel’s hardware designs (schematics and layouts for Tessel and all modules) here: https://github.com/tessel/hardware

    Whew! Now that you understand everything about Tessel, you’re all set to contribute to this open source project!

    See you on the repos,

    #kelsey breseman #contribution guide #tessel #technical machine #howstuffworks #software #hardware #lua #javascript #compiler #runtime #firmware #cli #how tessel works #how to run javascript on a microcontroller #javascript on microcontrollers

  • Twilio, Tessel, and the Internet of People

    Tuesday, September 16, 2014

    9/16/2014– Jon McKay

    Twilio and Tessel

    Twilio is a company that is near and dear to our hearts at Technical Machine. We’re excited to announce that their Node.js library runs on Tessel. Twilio is the SMS and Voice glue for any communications-based applications and they have an amazing developer experience. Hands down, Twilio is the easiest way to send SMS and voice communications and I’ve yet to meet a dissatisfied customer.

    In my opinion, Twilio and Tessel seem like a perfect match. Tessel is the fastest way to gather data about the physical world, and Twilio is the fastest way to get that information to the people who care.

    Why SMS?

    There are a whole slew of ways devices communicate with each other and with people: lightweight, data transfer protocols (MQTT, CoAP, XMPP, BLE), haptics, or visual displays. But what happens when an individual needs to be notified of an event regardless of where they are in the world?

    SMS is the best way to immediately get data to to the right person. While push notifications are also a reliable way of getting information directly to a user, it still requires them to download yet another app. As more and more connected devices have their own applications, it becomes increasingly tedious to download and use a separate smartphone application for each. Text messages are still the simplest way to get data from a device to a smartphone.

    Running Twilio on Tessel

    When we shipped Tessel, the runtime wasn’t compatible enough with Node for the Twilio Node.js library to run on Tessel. Not only that, but our WiFi state machine was unstable and prone to crashing making HTTP requests unreliable.

    We’re really proud of the progress we’ve made since then to get the Twilio Node.js library running directly on a microcontroller. We’ve slogged through a whole slew of WiFi, JavaScript, and Node compatibility bugs for this library to start working. We’re starting to see other libraries (like Keen.io and MQTT which we’ll talk about more soon) Just Work on Tessel and it’s really exciting to see our original design finally coming to fruition.

    We worked Ricky Robinett, a developer evangelist at Twilio to test out the Node library as we were fixing it. He was able to write a simple app on Tessel to get an idea of exactly how lazy his dog, Gif, really is. Using the Twilio Node library and the accelerometer module, he could detect when his dog was napping on the job, and send him a text with the nap duration. While it is an, admittedly, silly use case, his blog post shows the basics of loading the Twilio node module, monitoring the accelerometer values, and posting an SMS with an event has occurred. Check it out if you’re interested in sending a text message from Tessel!

    Note: SMS in production

    Lastly, running Twilio on Tessel is the fastest way to prototype an SMS-enabled system but you would want a different system design when moving to production. For example, you could move to a proxy-service oriented architecture: Tessel would send an HTTP request to a remote server and that server would take care of interacting with the Twilio service. The proxy server could also route incoming SMS messages down to the Tessel.

    If you’re building an SMS-enabled Tessel application and you’d like help, feel free to post on our forums or shoot me an email at jon@technical.io.


    #twilio #node #tessel #compatibility #wifi #sms #iot #internet of things #internet of people #node.js #javascript #ricky #robinett #jon #mckay #jon mckay

  • We’re hiring, cool projects, and meeting up

    Monday, September 15, 2014

    9/15/2014– Updates

    We’re hiring

    We miss our summer interns– seven people is too few for our grand plans! Check out tessel.io/jobs if you think you can help fill the hole in our hearts.

    Progress report

    Here’s what we’ve been up to lately: * Bug fixes and feature requests, as always. See the changelogs here. * Prep for conference/hackathon season: there should be Tessel hardware to borrow at most of Major League Hacking’s hackathons, and we’re speaking and providing hardware at a number of to-be-announced conferences. * Improved internal testing infrastructure: we’re working on a continuous integration server that automatically runs a suite of tests on every PR through Tessel and merges if acceptable. * Added contribution labels to Github issues to make it easier to contribute– see details here. * Added Tessel Packs to the store: bundles of modules for specific applications, such as the Hackathon Pack. * Reached out to a lot of customers for feedback– we love to hear your feedback, so much so that Jon spent a lot of time last week individually emailing customers to hear their thoughts. If you have anything to share, please let us know! * Made a meetup group in the Bay Area and held our first couple of events. * Got LuaJIT running some JS scripts.

    Meeting up

    Hardware is more fun in person– want to start a meetup group in your area at the intersection of hardware and web development? Reach out to kelsey@technical.io for support and ideas– and we’ll cover your meetup fees. Check out our group as an example.


    We’ve been watching projects roll in, as well. Here are a few picks: * Tessel + Auth0 authentication * Neopixel animation over websockets * A ring level using accelerometer + Neopixels * A Meteor.js temperature monitoring dashboard

    Do you have a Tessel project you’ve been working on? Please post!

    Until next time,
    Kelsey, Tim, Ken, Eric, Jon, Jia, and Kevin

    #update #updates #luajit #jobs #interns #hiring #startup

August 2018

January 2018

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013