0.3.0 Is Here!

in news

featured image

ThingStudio 0.3.0 is now live! It includes a new data transport (HTTP), feed processors, app-level CSS, JS & Documentation, as well as substantial improvements to the app viewer.

As many of you know, we’ve been cranking on the latest major point release of ThingStudio for the last month or so, which includes: major updates to transports, UI improvements and ‘breaking ground’ on a new version of the app viewer. So, without any ado, at all, here we go.

Our second transport: HTTP

While going from 1 transport to 2 may not sound like a big deal, it’s surprisingly complex. With one transport, you can just assume ‘connection’ refers to one thing with well-defined, unchanging properties. This assumption propagates all the way through your code base. In our case this ‘connection’ assumption was MQTT.

Since day-one we’ve been planning to add multiple transports, but our most advanced users really started to push us towards not only adding another transport, but HTTP specifically. So, we’ve finally tackled this and it’s working great.

While MQTT probably remains the “destination transport” for IoT in our opinion, HTTP is both a great starting point for people new to IoT and accustomed to its request / response paradigm, there are also strong cases to be made for HTTP as a valid part of the IoT transport suite. So there you go.

Other transports we’ve got in mind: web sockets, server events, Bluetooth, COAP, not necessarily in that order. Any of these more important to you than others? Any we’ve missed? Let us know in the comments.

Feed Processors

Inherent in providing HTTP support, and really scaling out MQTT provider support, is the need to add feed processors to handle data in all kinds of formats, make them modular and of course, easy to manage with a great UI.

To quote our feed processor docs:

Feed processor are routines that change the data going in and out of a feed into a form that can be managed by the rest of ThingStudio. There generally two types of feed processor for each transport, processors that manage incoming data, and processors that manage incoming data.

Feed processors need to be registered, that is, declared somewhere in your App’s javascript. They are registered by a call to ‘RegisterFeedProcessor’, which takes the following parameters


This is the name which will be displayed in the select box when in the feed properties page.


There are generally two types of feed processor for each transport. For example, for the HTTP transport, type can be HTTPRequest, or HTTPResponse, to process the outgoing and incoming data respectively.

For more details on feed processors, see our documentation.

New App Properties: CSS & JS

So, first the good news: no more “themes” as a top level object. We still feel it is important for you to be able to spin your own styles for your apps, but to have CSS as a top level object in the system, where JS was always aligned specifically to templates, was just awkward.

Now, the great news: you can now have app-level CSS and JS (as mentioned in the Feed Processors section), and template-level CSS and JS, as always.

The idea here is pretty straightforward: CSS & JS which are global to your app go in the respective tabs in the ‘edit app’ screen, while CSS & JS specific to a single template go in the ‘edit template’ screen. No surprises here.

Another New App Property: Documentation

When you start getting serious about your IoT apps, you’ll need to start providing documentation of your own; for your reference and for your customers. We’ve added a home for this, also in the ‘edit app’ screen. The editor has full support for markdown, so have at it.

IDE UI Improvements

So as we talk about the future of ThingStudio amongst ourselves, as well as where much of the IoT industry stands in late-2015, we frequently return to the fact that right now the IoT game is more about discovery than anything else with regard to delivering the scale of value expected of it.

This discovery for us also translates in to the visual language with which we present the robust, production quality capabilities of ThingStudio.

Information Density

When you login, you’ll see that the “information density” of the UI for the IDE is noticably higher than in 0.2.0. We believe this will translate to a more comfortable user experience, and higher productivity in the system. We strongly believe that ThingStudio not only has to be powerful, but a pleasure to use. If you ever feel we’re failing here in one regard or another, give us a shout!

You’ll continue to see the information density increase somewhat over our next 3-4 releases, as we make ThingStudio feel more like the workhorse IDE it is. But it will always be beautiful, fast and fun to work with. You’ll also see the UI “smarten up” in some pretty cool ways. Stay tuned.

Multiples: Feeds & Connections

By adding our second transport, we had a lot to think out, including the UI & UX for managing multiple types of any top level object – a paradigm the system had never previously had to solve for. Figuring out the best way to present the ability to add multiple transports (and inherently, feed types), which would need to scale to 3, 5 or maybe even 10 or more transports, we had to find a new UI pattern to present this capability.

Originally, somewhere between 0.2.0 and 0.3.0 on our test environment where our beta testers provide feedback to us, we had the multiple transports available in the sidebar. But this created an inconsistency with the sidebar icon rhythm you are used to, and we didn’t want an icon soup by having an icon for each new transport. Plus, let’s see you make an icon for web socket that’s distinct from HTTP, MQTT, COAP, Bluetooth, server events, etc. 🙂

Breaking the user experience in this way didn’t even solve for the creation of new items of each type of object. This was a non-starter made even worse.

As Joe Sparano famously said:

“Good design is obvious. Great design is transparent.”

We went with a single list of the combined types of objects (“Feeds” includes MQTT and HTTP feeds, “Connections” includes MQTT and HTTP connections), and we replaced the previous “drop down form” you were used to with a plus-sign dropdown, which takes you directly to full-page forms where you can create new items with enough screen real-estate to think clearly.

While this may seem obvious now (it sure does to us), it was a good number of impassioned discussions in the making.

Viewer UI Updates

So as many of you who have built stuff in ThingStudio can probably surmise, the app viewer has historically been the weakest part of the user experience in ThingStudio. This release represents our first steps in creating not only a top notch user experience for the viewer, but also preparing for a native app (iOS / Android) release coming soon.

Historically, we didn’t put much focus here because we provide you the tools you need to spin your own nav structure, etc. But as we realized with widgets, it helps to give people an attractive, easy to use starting place, and let them evolve their UIs at their prerogative as their needs develop.

We rewrote almost all of the code for the viewer from scratch based on an understanding that comes from the sum of our collective experience on what ThingStudio needs to grow in to, and it’s a whole lot better. Like, by a mile.

When you login, hit the new “View App” button in the top of the left-hand sidebar to check it out. We think you’ll be pleased with the progress.

But, we’re still a long way off from where we want to be with the app viewer. We’ll be improving on the viewer with each major and minor release based on your feedback and our roadmap. The end game here is a top notch native application which is dynamically populated with your IoT apps and UIs, with everything you’ve come to expect the experience of modern mobile applications, while remaining completely flexible to the demands of your implementation.

Wrapping up

So, those are the biggies for 0.3.0. Give it a shot and let us know what you think.

Ciao for now.



Paul likes to work on growth, product & design. Tweets occasionally @paulisloud. Currently working on GuruGate.


  1. Joan

    I love the thingstudio idea, but for me it a must to post data to a thingstudio URL like emoncms,

    Do you have any plans to add this feature?


    1. Paul Grieselhuber

      Hi Joan,

      It’s pretty straightforward to get data in and out of ThingStudio – could you provide some more details on what you’d like to accomplish?

      If my understanding is correct, you want to integrate ThingStudio with InfluxDB. We’ll be publishing a recipe on this shortly so stay tuned.

      1. Joan

        Thanks for your quick reply.

        I want to post data to Thingstudio in this way:


        In this way I can run the http client on my Particle Photon to post data to thingsstudio,

        I don’t want to mess with MQTT, and this HTTP feature shown in this post only work as a client right? Or I can post data using this?


  2. Mike Karliner

    Thanks for the question Joan, because its an important one and deserves a answer at some length. But first the short version:

    No, you cannot do an HTTP POST to “ThingStudio”.

    ThingStudio consists of an IDE, which is where you create your applications and templates, and a runtime which is what runs them. The runtime runs in your browser.

    There is no ThingStudio “server” to POST your data to, and you can’t post to the browser as your Photon will have no idea where the browser is (in terms of an IP address), and even if it did, your browser may not be accessible to your Photon, ie: you are on your phone, away from home, and your mobile data provider has put your phone in a private network, which is what usually happens.

    The long and short of it is that in IoT there is almost always some system between the device and your UI. In the case of emoncms, there is the emoncms servers, which you have to host somewhere. If you want to POST out of your Photon, you will need some server in a known place to POST to. There are a great many IoT platforms. Phil Zito has taken on the task of listing them all here: http://blog.buildingautomationmonthly.com/iot-frameworks-database/ which is a very useful resource. It’s worth noting that out of all of the listings ThingStudio is one of the few that focusses on the User Interface, as distinct from data visualisation.

    A good practical choice for hacking is node-red which is very popular as a middle processing layer for IoT, makes it pretty easy to set up a web service POST to and store data.

    Indeed, we’ll be publishing some recipes about how to do exactly this and use ThingStudio for the UI. We also intend work on a recipe about using node-red and time-series databases.

    ThingStudio is intended for use as a general purpose UI system, which includes sending control data to devices as well as monitoring them.

    Because there are so many platforms, providing data storage and processing, both cloud based and self hosted, we made a conscious decision not to provide these services, but work on the best UI toolkit which could easily work with just about all of them.

    I hope this helps you to understand our thinking, even if you decide that ThingStudio is not for you.



Leave a Reply

Your email address will not be published. Required fields are marked *