Enabling hardware is a critical component of any telematics/IoT solution. From scooter sharing to heavy machinery tracking to stationary fuel tanks monitoring — specialized IoT hardware is at the heart of any IoT solution. The number of use cases increases constantly and so does the demand for the right hardware devices to support them. The recognition of how rapidly IoT space is growing has led a lot of new entrants to get into the IoT hardware business. What we are seeing now is that for each vertical niche hardware choices are also vast. Clearly, the competition among hardware manufacturers is intensifying very rapidly.
A very curious aspect about this increasing competition is that new entrants recognize the common pain points and inconveniences, apply some innovative and smart thinking and design their business models in a way that solves them. As a result, they quickly start posing a threat to large existing players, who may not adapt quickly enough.
One of those common pain points is a lack of API access to telematics data, generated by IoT hardware. To illustrate this particular point, let’s review the “traditional” way of enabling data consumption from the devices. As part of the device design process the IoT hardware firm writes the firmware that contains a set of instructions, which device would execute in order to capture telematics and auxiliary data, form data packets with the binary payload (that contains “useful” data) and push those data packets to the end-point on the internet via TCP or UDP connection. Now, in order to consume that data the solution integrator must:
Set up so-called listener servers with open ports and “listen” for the incoming connections from the devices out in the field.
Use protocol documentation from IoT hardware company to build parsing scripts in order to “decode” binary payloads into the data messages containing clear values and descriptors for telematics and auxiliary data points such as latitude, longitude, time, ignition, battery level, etc.
Have a process in place to update parsing scripts should the firmware be updated (can happen quite often) or changed to the extent it modifies the way payload is constructed.
All of the above steps must be done by the solution integrator before being able to start using data in their purpose-built IoT application. Does that sound easy? Is that something IoT solution integrators out there enjoy doing as part of building their solutions? No. After working in the industry since 2013 and talking to lots and lots of solution integrators, I can confirm with absolute certainty — they all would avoid it if they could.
That is something new IoT hardware companies recognize well and therefore provide API access to their devices as part of their standard offering. Some examples include NimbeLink, Invers, BeWhere. The reality of the year 2020 is that as an IoT hardware company, unless you offer API access to the normalized data from your devices, you are at a competitive disadvantage in an ever-growing number of competitive opportunities.
To be fair, there is a good number of white-label platforms out there, such as Wialon, Navixy, GPS Gate, and others, with whom you might be sharing common customers. Companies operating those platforms at scale have built the integrations steps above into their operational model and don’t mind it. It actually makes a lot of sense for them, as their business scales wonderfully and the same parsing script gets leveraged by dozens, hundreds, and thousands of integrators. So that part of the business from our perspective is safe. However, if you want to be competitive with IoT solution integrators operating their own software platforms, API access is a must.
The good news is that flespi already has exactly what you need to immediately enable access to the normalized telematics data generated by your devices.
Normalized telematics device data of every manufacturer supported by flespi can be accessed and consumed in JSON format via a very straightforward REST API. In fact, that’s just one of several ways flespi can enable the consumption of the normalized data. But the best part might be the price. As you know too well, charging integrators upwards of $1–$2 USD per device monthly for API access is not uncommon (sometimes those costs include airtime, and API+airtime access is expectedly more expensive). Flespi’s per device cost is $0.10/unit at 1000 units (assumes 1000 devices and 1GB of storage; full pricing model is here) and goes down with a higher volume.
As APIs become more and more of an expected way of consuming telematics data, it’s important to keep up with this trend and give solution integrators such option. And the easiest way to do so is by pointing them to flespi.