• This Week in Tessel: Special Report from Tesselcamp

    Monday, September 12, 2016

    Hello, Tesselators!

    Tessel Project leadership met up at Tesselcamp to determine the organization’s goals and main activities for the next year. In this special issue of This Week in Tessel, we’re reporting back to you:


    • We’ve set goals for the next year focusing on growing community and making it easier to use Tessel 2 in production. Read the specifics.
    • There are working groups to go with the goals, and we’d love to have you. Check them out here.
    • There are new releases out for T2 CLI (including Node 6 support) and Firmware. Plug in your Tessel and run npm i -g t2-cli; t2 update to use them.
    • Documentation now includes more of the stack.
    • Repos are now more contributor-friendly than ever with badges and standardized labels.

    Part of the @tesselproject team at Tesselcamp, photo by Flaki.

    Goals for the next year

    The two key goals for the next year are:

    1. Grow the community to increase contributions and encourage both inclusion and accessibility to newcomers.
      • Build effective working groups that can complete their tasks with measurable results.
      • Upgrade our documentation. Build more fritzing examples, API prototypes, and call out features that are currently missing from the docs.
      • Update the tessel.io website to more accurately represent the project and its plans.
    2. Support and grow the number of production deployments of Tessel in the field.
      • Research and create a guide for production-scale deployment of a Tessel project. Base this on the needs of current users.
      • Build Tessel Reach, the low-power hardware endpoints of a star network whose center is Tessel 2, so Tessel can make sense in more use cases.
      • Build first-class support for Rust API and documentation (parity with JS) and figure out JS-Rust inter-exection to provide for performant high-level coding of serious applications.
      • Investigate increasing RAM and Flash availability on Tessel or a revision of the Tessel board, reducing friction in production-level deployments.

    Read more in the Tessel Project readme.

    Working groups

    To accomplish the outlined goals, the team decided to form working groups as follows:

    • Learning WG: investigate user needs for production & write a guide on how to take a Tessel project to product scale. Also build and document GPIO/GUTS (Great Uses for Tessel in Stuff e.g. hacking a production system) projects. Learn more/get involved
    • Website WG: Create a better website for what we are & what we plan to be based on this year’s goals. Learn more/get involved
    • Rust WG: Get Rust to 1st class support
    • Reach WG: Ship Reach
    • Memory WG: Investigate strategies to make larger projects deployable on T2, possibly as a 2.1 Tessel hardware

    Since working groups are new for the project, we’re rolling out these groups slowly. The Learning and Website WG’s are our pilots. See the working groups section in the Tessel Project readme to learn more and get involved.

    Please get involved! It is our hope that working groups make it easier for people to engage with specific facets of the Tessel Project.

    Updates from the Repos

    Tesselcamp also included lots of work time. This helped us release new versions of T2 CLI, firmware, docs, and our repos!

    We recommend you update CLI and firmware with npm i -g t2-cli; t2 update so you get the benefits of our latest work.

    CLI Update

    • The node-usb module has been moved to the Tessel organization. Thanks to Kevin Mehall for being its lead developer and maintainer!
    • We’ve updated its CI infrastructure to publish binaries for macOS and Windows for all current Node versions.
    • As a result, we were also able to publish a new version of the T2 CLI. You no longer have to run Node 4.x to talk to Tessel from the command line; any Node version 4.x, 5.x, or 6.x is supported.

    Here are the full release notes for T2 CLI 0.0.27 and 0.0.28.

    Note: Tessel 2 still runs Node 4.x as it’s the current LTS (long-term support) version. The next LTS release is coming up in October, and we expect to release Node 6.x on Tessel at that time. You can follow our progress in upgrading Tessel 2 for Node 6.x support, and help us design a release process for supporting new Node versions going forward.

    Firmware Update

    The version 0.0.14 release of the Tessel firmware includes a variety of stability improvements for USB and GPIO communications.

    • This error should be long gone!
    • A few Network API bugs were squashed as well, making the returned network information more consistent.
    • The Tessel.Port.close method was added to allow closing power to individual ports, i.e. tessel.port.A.close() will turn off power to Port A. One or both ports can be opened again using tessel.open('A') or tessel.open(). More control over the power to the ports means more energy efficient projects!

    The full release notes can be found here.

    Docs Updates

    From the many recent updates to the Tessel docs, the most notable are:

    • The Debugging section now includes more documentation about Tessel 2’s full tech stack and how to interface with the Linux filesystem. This reflects the philosophy that you should be able to hack Tessel on any level, not just through the API we expose. It also helps blur the line between Tessel “users” and Tessel “contributors”.
    • The Tutorials section has new documentation on Pulse Width Modulation: what it is, how to use it, and diagrams for experimentation. We hope to do more in this space with other signal protocols in the future – please post an issue on the T2 Docs repo if there’s some electrical concept you’d particularly like to see more examples of.

    There is always more to do in documentation. Check out some of the well-outlined starter issues if you want to help the community learn!

    Contributor-friendly repo updates

    We try to make our repos as friendly as possible. A couple of new additions include:

    • We’ve added Code of Conduct badges to our active repos. This is an efficient way to explicitly link every repo to our Code of Conduct, and serves as a visual reminder to all visitors that we’re a caring community.
    • Standardized labels across our active repos make it easier to get work done. In addition to our contribution-starter label (where we take special care to point you in the direction of relevant documentation), there’s a design label for graphic design on some repos, and a discussion label for issues seeking advice and considered opinions.

    That’s all for this week!

    Usually, we’d have some links to projects and talks here, but we don’t want to wear you out with this email!

    Please feel free to submit talks, blog posts, projects, and more to the next newsletter. In the meantime, see you online.

    With love,
    Everyone at the Tessel Project

    This Week in Tessel is where we highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    #tessel #tesselcamp #open source #open governance #update #updates #twit #goals #working groups

  • The Tessel Crash Reporter service

    Friday, September 9, 2016


    Do you want to know how the Tessel team identifies and fixes problems in the Tessel command line interface (CLI) without requiring users to reach out to the Tessel team? Say hello to the Tessel 2 crash reporter.


    The Tessel 2 crash reporter is a web service which automatically collects anonymized crash reports when a crash is detected in the Tessel 2’s CLI. Given that the CLI is one of the primary ways of interacting with your Tessel, it is important that the CLI be extremely stable and a joy to use.

    This project started during the early days of the CLI. We wanted to make sure that the team was proactively looking at and fixing issues as users encountered them. We wanted to make sure that the onboarding experience was as smooth as possible for new users.

    How it works

    Every time you use the Tessel 2 CLI, a central controller dispatches your command to an appropriate task handler. The crash reporter automatically checks for uncaught Errors and unresolved Promises in the node process that’s executing the task.

    Once the crash reporter detects a crash, it removes all personally identifiable information from the stack trace, and uploads it to the Crash reporter web service with the user’s permission. After the user opts-in the first time, subsequent crashes are automatically reported. Below is an example of what that interaction looks like:

    ERR! Detected CLI crash [Error: Testing the crash reporter] Error: Testing the crash reporter at  CrashReporter.off.CrashReporter.on.CrashReporter.sanitize.CrashReporter.sanitize.redactions.CrashReporter.prompt.CrashReporter.submit.CrashReporter.prompt.then.CrashReporter.post.CrashReporter.status.CrashReporter.test (/Users/rahulrav/Workspaces/Tessel2/CLI/lib/crash-reporter.js:177:25)
    at process._tickCallback (node.js:406:9)
    at Function.Module.runMain (module.js:449:11)
    at startup (node.js:141:18)
    at node.js:933:3
    INFO Detected a crash in the CLI. Submit crash (y/n) ?
      If yes(y), subsequent crashes will be submitted automatically.

    We put a great deal of thought into potential privacy issues, and decided to make this feature opt-in. The user can also turn off crash reporting simply by using one of the below options.

    Usage: t2 crash-reporter [options]
      --off    Disable the Crash Reporter.
      --on     Enable the Crash Reporter.
      --test   Test the Crash Reporter.
    Configure the Crash Reporter.

    The service

    The Crash reporter web service collects the crash report, and de-duplicates it using the Sim Hash algorithm. Sim Hash looks at the contents of the crash report and computes a unique signature (called the fingerprint) and also keeps track of the frequency of the occurence of the report. The service also provides a way to look at Trending crashes and also provides a full text Search API. The service itself is built using Google App Engine and the Python Runtime. The full source code for the service is here.

    Hi from tessel-crashbot

    Recently, we landed a really cool feature in the Crash reporter service. In an effort to simplify the worflow of the Tessel team, which manages all feature requests and bug-fixes using GitHub issues; the Crash reporter service uses GitHub’s API to automatically create and manage issues for every crash report. Anytime there is a new crash in the wild, the ever friendly tessel-crashbot is ready to help proactively keep track of the problem. The tessel-crashbot also updates the GitHub issue via comments when it sees an uptick in the frequency of a crash. This helps the team identify the severity of a crash report.

    Image of crashbot submission.

    #update #this week in tessel #twit #updates

  • This Week in Tessel: the busy summer issue!

    Thursday, August 25, 2016

    Hello, Tesselators!


    Tessel Community Survey

    We’re researching the next direction for Tessel Project hardware, and we have six questions for you.

    Help us out by telling us what the future of connected things should look like on this survey!


    The Tessel Team (the Steering Committee and some of the Team Members) are meeting in person the first time at Tesselcamp next week.

    The event will be a low-key three-day session in New York City for core community members to discuss vision, focus on key issues, and spend time together as a team.

    The final day of Tesselcamp (Saturday, September 3) is a community day, in which members of the public are welcomed to use the hardware and expertise of the core Project members and get up to speed contributing to the Project. If you’re in the area, please come!

    For those not in the area, we encourage you to spin your own “welcome to open source” themed events. Want to host one in your local community? Get in touch; we would be happy to help.

    Nodebots Day Recap

    We mentioned International Nodebots Day in the last newsletter, with a special mention of the Johnny-Five Inventor’s Kit as the kit of choice for a few of the event locations, like NYC and Miami. The Tessel 2 was also used to power Sumobots at Houston’s event, with a great recap by Justin Gosses.

    Check out @nodebots on Twitter to see pictures and video from other events around the world!

    More Tessel: Links Roundup

    Things to try

    Things to watch and read

    That’s all for this week! Feel free to submit to the next newsletter. In the meantime, see you online.

    With love,
    Everyone at the Tessel Project

    This Week in Tessel is where we highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    #update #twit #this week in tessel #updates

  • Meet a Tesselator - Kelsey Breseman

    Tuesday, August 16, 2016


    A somewhat tired Kelsey Breseman backpacking in Iceland

    A somewhat tired Kelsey backpacking in Iceland

    How did you get involved with the Tessel Project?

    I wasn’t involved much in microcontrollers, or even programming, before Tessel. I’d worked with both a bit in college, but it wasn’t a guiding passion for me.

    The summer after I graduated, I was living with several friends, including the team of three that was founding Technical Machine to build Tessel.

    I had a work-from-home contracting job at the time. Our apartment had no air conditioning, and Boston was really, really hot that summer. So I started showing up at Technical Machine’s office space, and grew interested in the proposition: how do you get people who have no idea what they are doing to try hardware – and not fail? How do you take the world of the Internet – obviously useful, but traditionally accessed via screens (pretty limiting and draining, in my opinion) – and better hook it up to the real world and to physical space?

    Within about a month of the company’s founding, I was showing up to work every day, writing about the project, getting more into programming, and getting involved.

    I can’t claim credit for the idea of JavaScript on a microcontroller, or the implementation (novel at the time) of Wifi on a microcontroller. But I am really proud of the influence I was able to have over the user experience. As a relative beginner in both JavaScript and hardware, I was always asking: how do we make this or that clear to people? How will this feature be understood by someone who has never picked up a wire before?

    As the project developed, I adopted an “I fight for the user” mindset and guided product development as Director of Community.

    Kelsey Breseman speaking at OSCON 2016: “How to build a product when nobody’s getting paid

    When we transitioned to open governance as the Tessel Project, I put together a lot of our new structure and rules and became one of the four founding Steering Committee members. Together, we (now five of us) run the project.

    What do you like best about being involved with Tessel?

    It has been exciting to watch this project and community grow.

    I travel around the world giving workshops on Tessel, and I love that moment, every time, when a person’s face lights up.

    “Oh my gosh!” they say. “It did something! I made it do something!”

    Most of the people I teach Tessel to are people who have never had a success with hardware before. Sometimes, I’m also teaching them to code– that’s a lot of fun.

    Kelsey Breseman live coding on Tessel 2 at NodeConf Oslo 2016

    The other piece that I love is building connections between people– inspiring them to work on things together.

    Community is powerful. If I were to take on the whole of the Tessel project by myself, it would die pretty quickly. But if I can inspire a few people to work with me on it, we can get a lot done.

    One of the biggest challenges is figuring out how to keep a distributed team inspired and engaged. Our team members mostly haven’t met each other!

    It’s an ongoing social experiment for me to create tools and practices that make people want to keep coming back.

    Kelsey Breseman and Flaki (István Szmozsánszky) discussing Tessel at RuhrJS

    I absolutely love when I go off in the woods for a few days, come back to the internet, and discover that someone I’ve never met or heard of has started working on one of our repos. Or, when community members ask support questions, and other community members respond without anyone from the official Team being involved. That feels like community success.

    Outside of Tessel, what are you working on right now?

    I’ve been thinking a lot about climate change recently: reading books and articles on the subject, trying to wrap my head around all the issues at play and the opportunities they create. I’m blogging about my thoughts and taking copious notes, both as a way to help me think.

    The plan is to start a company in this space, though I’m not sure yet of the exact proposition. Climate change is going to require a lot of people to work hard on interesting new problems. I would like to be involved in connecting smart people to interesting, meaningful problems.

    Do you have any advice for people who want to get involved with the Tessel Project?

    Jump in with both feet. We’ll catch you.

    People are sometimes nervous to start contributing to the Tessel Project. By its very nature, it gets people from one field interested in another field they don’t know much about (web, hardware, and vice versa).

    My advice: contribute even if you feel completely unqualified. We have a number of open starter issues.

    This is how you learn. It’s hard. You feel stupid. You put yourself out there on the internet. But we’re here, and we want to help you.

    Sometimes, what you need is a good project to learn on. Tessel was that project for me, and I hope it can be for you, too.


    Kelsey Breseman

    #kelsey breseman #meet a tesselator #tessel project

  • Interfacing with the Language Plugin API for Tessel 2

    Tuesday, August 9, 2016

    This month we merged one of the most significant pull requests for the Tessel project: adding Rust deployment support. For the past three years we’ve focused exclusively on deploying JavaScript on microcontrollers. This is our first step investing in a new language, a new ecosystem, and a new community. However, the purpose of this post is not to dive into the benefits of Rust, but rather to showcase the ease of adding new language support to the Tessel CLI.

    Despite the significance of this addition to the CLI codebase, the amount of code we modified was relatively small. We simply added two main files (along with minor modifications to a handful of other tests): one with the implementation and one with unit tests. The simplicity of the feature addition is a testament @rwaldron’s hard work building the CLI’s language plugin system. In this post, I want to demonstrate how straightforward it is to add support for a new language to the CLI using this plugin system.

    You can deploy an arbitrary code bundle to Tessel 2 (in any language) with the same six general functions:

    1. Determine project location in the file system
    2. Run any compilation/pre-processing steps (optional)
    3. Bundle the executable code into a tarball
    4. Run any pre-execution steps (optional)
    5. Execute the code/binary
    6. Run any post-execution steps (optional)

    These functions are more concisely named checkConfiguration, preBundle, tarBundle, preRun, shell/binary, and postRun (respectively). Here is an explanation of each of those interfaces.

    1. checkConfiguration

    checkConfiguration accepts the directory that was deployed with t2 run ... and returns the path to the entry point of the project. With Rust, we do this by parsing the Cargo.toml and with JavaScript we parse the project’s package.json. It is expected to return an object with a basename and optional program property (for the name of the project).

    // checkConfiguration to confirm project deployment files
    exportables.checkConfiguration = (pushdir, basename, program) => {
      // Should return the file information for the program
      return {

    2. preBundle

    preBundle is an optional step for any processes that need to be run prior to packaging the directory that will be sent to the Tessel 2. For example, when deploying JavaScript, this function is integral to the binary compilation stage (where we inject our pre-compiled binaries in place of existing project binary dependencies). For Rust deployment, this step is less critital but we use it to set some optional parameters (which we could do in the next function as well).

    // Optional function to process options prior to bundling project
    exportables.preBundle = function(options) {
      // Should return a Promise which gets resolved when the code is ready to be tarred
      return Promise.resolve();

    3. tarBundle

    tarBundle is a required step which should resolve a Promise with a Buffer that represents the tarballed code or binary. The CLI will automatically untar the bundle after it is deployed on the Tessel 2.

    In the case of Rust, this was the biggest addition. In order to compile Rust code for Tessel, we needed to set up a special cross-compiler that could compile a binary that runs on Tessel’s MIPS architecture. The easiest solution was to have the CLI send out the project to a preconfigured remote cross-compilation server. The server then compiles and returns the binary to the CLI.

    // This must implement a Promise that resolves with a Buffer
    // that represents a DIRECTORY containing the desired bundle.
    exportables.tarBundle = function(options) {
      // Should return a Promise which eventually gets resolved with the bundle
      return Promise.resolve(bundle);

    4. preRun

    preRun is an optional step that’s useful if you need to call any shell functions on Tessel itself before the project is initialized. For example, with Rust, we set the permissions of the binary to ensure it’s executable. It’s unused for JavaScript.

    // Optionally make changes within Tessel's Linux environment before starting the program
    exportables.preRun = function(tessel, options) {
      // Should return a Promise which eventually gets resolved
      return Promise.resolve();

    5. shell/binary

    t2 run

    binary is a string that represents the engine that runs the program. It is used as the first argument in a shell command to start the program when a project is run. For JavaScript, this string is node and for Rust it’s ..

    t2 push

    shell is a function that could have been named begin because it’s responsible for actually getting the program going when you push the project. The reason it’s called shell instead is because the function needs to return a string representing the contents of a shell script that starts the program.

    exportables.binary = 'YOUR_EXECUTION_METHOD';
    exportables.shell = (options) => {
      return tags.stripIndent `
        exec YOUR_EXECUTION_METHOD /app/remote-script/${opts.resolvedEntryPoint}

    6. postRun

    postRun is another optional step that’s useful if there is code you need to run on Tessel after the program has started (but not necessarily before the program has ended). It’s largely unused thus far so far but was added for future-proofness.

    // Optionally make changes on Tessel after starting the program
    exportables.postRun = function(tessel, options) {
      // Should return a Promise which eventually gets resolved
      return Promise.resolve();


    That’s just about all there is to adding language support to the CLI. There are several more steps that need to be taken to build full hardware support for a language on Tessel. You can follow Rust’s progress in that process here.

    If you have questions about the unit tests or the implementation of new languages in general, feel free to reach out in the #engineering channel of Tessel Slack. Let us know if there are any extra plugin functions you think the CLI needs to accomodate or if you need help building a plugin for the language you’d like to build hardware with.

    • Jon

    #tessel rust programming language plugins deployment compilation

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