The flespi team is creating the product for you. And we design it for you to use it efficiently. However, we often ask you to look at the process of creating flespi-based applications with the eyes of flespi developers.
That’s why we have so many open-source projects: we want to show the best practices of using the flespi API.
That’s why we have so many articles about flespi architecture: we want to share great experience in creating high load solutions.
That’s why we created a built-in chat in the flespi panel: we want you to ask for advice when you need it.
We, in turn, always try to look at flespi from the users’ standpoint. We want to understand what may look counterintuitive or unusual, what features are anticipated next, etc. Fresh look allows to find system inconsistency and API misbehavior, clean up the platform from unnecessary complexities.
The point of view definitely matters:
In this article, I will try to look at the platform with the eyes of a user that needs to understand the concepts of flespi. In general, users face three (as Prince William kindly shows us) main questions (with different time and priority relations):
How to solve my task with flespi? (the vital question that must be answered right now).
What potential problems can arise and how they may be addressed by existing features? (a tactical question related to near future).
How else can I benefit from the platform? (to define the development strategy for the long term).
When looking for answers to the above questions our users tend to consider platform costs and development complexity. Let’s use these factors to assess flespi functionality in relation to different business needs.
Stage 1. Gateway
Most Telematics Hub users come to us with a simple need: get data from tracking devices. This exactly fits the term “Gateway”: the data comes from the trackers, gets processed inside and structured, and unified messages are available in the output. We can use the analogy of a woodworking factory: cut-down trees come from one side (raw protocol packet) and pretty standardized boards and fenders (unified messages) come out on the other side. flespi wood factory has pickup points (various API), and own delivery system (streams).
Platform costs: for $100/month user gets three channels (50K trackers per channel), several types of API, easy integrability with world-class platforms, and handy open-source add-ons making it easy to receive data.
Note: There is also a free version with two channels (100 trackers per channel) which is usually enough for testing and small projects.
Development complexity: The fewer functions you use the less integration is to be done. Receiving messages from your devices from flespi is easy with MQTT: create an MQTT client, authorize with the flespi token, and subscribe to the appropriate topic.
Conclusion: This is a fully self-contained scenario of flespi gateway usage: create a channel, connect a device, receive data in a number of ways. But this implies that you have to do a lot on the User Application level: separate data from different devices, store messages, hold intermediate results of operations with devices (e.g. sending commands and waiting for the response). Be aware of that.
Stage 2. Registered devices
The second question deals with advanced flespi features — if the simple gateway is not enough. A user can register a device instance and get access to a number of useful features:
group messages received by the gateway based on device ID
store up to 10 GB of data for each device for up to 10 years
change the device settings using the online configuration tool and store current settings state
get the latest telemetry information for each device (state and update time of each parameter received)
use simple open-source tracking application TrackIt!
So if the gateway is a woodworking factory, registered devices layer can be compared to a timber subsidiary with a spacious warehouse and sorting node where boards can be classified according to quality, size, and wood type. Moreover, the quality assurance department can contact the raw material supplier to track the quality of the incoming material.
Platform costs: for the base $100/month you can register up to 1,000 trackers. Additional devices will cost $0.01/month each. 1GB of long-term storage costs $1.
Note: with the free version you get 10 registered devices with no possibility of extension.
Development complexity: flespi has a lot of native features to create an application with complex Business Logic:
storage system for device messages is not only huge and long-term — it was developed specifically for telemetry messages. It means that you can use API to filter, sort, combine messages, and even calculate some common values!
device configuration process is rather complex and time-consuming. And the list of problems that can be solved with just changing device settings is really huge!
ready to use solutions like Telemetry or TrackIt! can significantly reduce development time compared to implementing it yourself.
Conclusion: Why reinvent the wheel? flespi comes with a bunch of tried-and-true solutions. Some registered device features may inspire you to have this in the Business logic of your Application. But more features may require more funds.
Stage 3. What’s next
What about strategic thoughts?
First, flespi users are ready to grow. Handling 50,000 connections on one IP:port is not a trivial task but flespi can do it. It means that flespi user will never get stuck because of backend performance — flespi will deal with 1,000,000 connections just as smoothly as with 1,000.
Next step — we have already released API for sub-accounts management which will help you arrange fleets according to your real clients’ device groups and set your own limits for sub-accounts.
And we got more features to come. Right now we are working on the Analytics module. Gateway deals with connections, registered devices extend your abilities in working with trackers as separate entities, and Analytics operates on the higher level of abstraction and gives you a set of tools to address your specific Business task.
Based on smart algorithms for processing telemetry messages, Analytics will be able to implement your custom calculations, trigger alerts, and collect statistics grouped by various intervals. In the analogy with the wood industry, Analytics will be a furniture factory where you just need to load the drawings of the final product and wait for ready-to-use chairs and tables. And if your devices are already connected to flespi, it will be much easier to start exploring the new opportunities.
***
We believe that your goal as our [potential] user is to deliver maximum value with minimal efforts at a reasonable cost. That is why we analyzed flespi from the functionality, complexity, and pricing perspectives so you could get just enough to accomplish your goal in the best way possible.