As an IoT developer, I’ve been fortunate to work on a ton of different projects in ThingWorx on all parts of the technology stack. I’m a big advocate of using the correct tool for the job. I’ve found that in IoT, the right workflow can make all the difference in keeping the development team moving quickly and efficiently.
Below are 5 IoT application development tools that I use consistently and may be helpful to you when creating your own IoT applications…
1. ThingWorx Academic Simulator
The ThingWorx Academic Simulator was built to enable developers who work on the cloud component of an IoT Solution to work independently of developers on the edge.
Let’s connect this to a commonly used IoT development framework – the ThingWorx development process.
Once the ThingWorx model has been designed and agreed upon
- developers working with the physical hardware can develop the edge agent(Connect)
- data scientists can start building predictive models (Analyze)
- developers working on the end user application (Build) can develop the API endpoints necessary for interacting with the model
The issue that arises is that developers working in the cloud, need data from the edge in order to fully test their application.
ThingWorx Academic Simulator was built specifically to solve this issue. The idea that lead to the creation of the ThingWorx Academic Simulator was simple:
What if there was a generic implementation of the ThingWorx AlwaysOn websocket protocol that could be set up and used via a GUI.
IoT developers can use ThingWorx Academic Simulator to connect to an existing data model (all remote properties and services are added and bound automatically) and then simulate the operation of an edge device.
For example, you can have an IoT washing machine that sends temperature and RPM information to the cloud via a user defined equation. This data is essential to anyone who is building the part of the solution that is visualizing that information or creating alerts for various failure states.
Data scientists can use this data as well by comparing the analytics result from their system to the equation defined in ThingWorx Academic Simulator. If their system is showing different results from the known curve, there is an issue with their system.
Disclaimer: My team and I personally developed this technology so of course it’s first on the list.
Postman is one of my all-time favorite IoT tools, and is a must have when working with ThingWorx. Most people use Postman to mock up and test REST API calls. This feature is really useful when working with platforms that have extensive APIs (like ThingWorx). But what makes Postman my favorite tool are the additional features.
Postman Pro gives you the ability to take a mocked-up API call and save it into a collection. This collection can then automatically be turned into a sharable online doc with no extra work needed.
This feature is a must have if you’re working in a collaborative environment where API endpoints in ThingWorx need to be called from an external platform.
Postman also can turn collections of saved API calls into QA tests. These calls can be run in sequence or with variables that change based on previous tests or different environments.
You also can define custom test parameters such as response time, or scrub a response to determine if the response is correct.
As if you weren’t able to do enough with the API calls that you mocked up, you can even tell Postman to run them periodically and alert you if there’s a test failure.
That means you can run a subset of your QA tests against your production environment to catch if:
- that platform is down
- a part of the system is no longer working correctly
- it’s simply taking too long to respond
While not particularly useful as the primary method of monitoring your application, you were going to mock up those API calls anyway, so why not use them!
Postman is so much more than just a tool for your developers to mock up API calls, it’s also:
- documentation for your product managers
- API testing for your QA team
- a monitoring system for DevOps
But the real beauty here is that your developers just have to mock up and save that call once to enable all of the other groups. And they were probably going to do that anyway!
3. Raspberry Pi
When the Raspberry Pi was introduced in 2012, it changed the maker community forever. Never before has a fully-featured computer been so widely available for such a low price. Since the release of the Raspberry Pi 3, the board has featured onboard Wi-Fi and Bluetooth, making it extremely useful for IoT projects.
The RPi is my board of choice when prototyping an IoT system since it is so flexible and easy to work with.
Since it’s running a full Linux operating system, you can write your edge agent in whatever language you want: Java, C, NodeJS, etc. Some other boards like the Arduino don’t give you that kind of flexibility.
Additionally, compared to most edge devices, the RPi is an absolute powerhouse of processing with its 1.2 Ghz quad core.
It’s flexible, has a great ecosystem of components designed for it, and is really inexpensive.
However, it’s not without its drawbacks.
For starters, it doesn’t have a built-in analog-to-digital converter (ADC) which means it can’t read analog signals from sensors.
Additionally, since the RPi is not a RTOS (real-time operating system), it’s not as useful for control systems as platforms like Arduino.
That said, anytime I want to do a proof of concept for an IoT system, I’m always grabbing for one of my dozens of RPi3’s.
Twilio is all about making automated text messages and phone calls from your application easy.
With an extremely simple API, and a native ThingWorx extension I find myself going back to Twilio for user notification systems all the time.
Everyone has a phone in their pocket, and it’s almost always the fastest way to reach someone. For example, automatically calling someone to let them know that their IoT system has detected moisture in their basement is a powerful way to add extra value to your system.
And Twilio makes this really easy, especially with ThingWorx. But be careful, Twilio charges for each text and phone call – which can add up quickly.
When I first started using Twilio, I was building a notification system that got stuck in an infinite loop while I was at lunch. I came back to over 2000 text messages and $100 worth of charges against my account. So be warned!
Amazon has been making waves with its in-home voice assistant Alexa, but has started to see heavy competition from Google and Microsoft.
Where I think Alexa really shines is with its Nature Language Processing (NLP) framework that developers can work with. Alexa exposes great tools and provides the infrastructure to make developing apps easy.
In particular, Alexa applications are developed with AWS Lambda which is a very flexible piece of infrastructure intended for micro services. Working in Lambda on an Alexa application, allows you to only work around the users “intent” when interacting with their application.
Alexa does the hard work here to break down a phrase the user is naturally saying, routing that phrase to a function (the intent) in Lambda, and then passing the slot value as an input into that function.
Once you’re in the function in Lambda, it’s easy to send that information elsewhere.
I often use Alexa as a way to interact with IoT systems without needing a screen or application (who needs those front-end devs?).
This by no means is an exhaustive list. There are tons of IoT application development tools out there with more popping up each day. But in my time working on IoT projects, these jump out to me as the ones you have to try.