Hello again! Just before I cover the way we were developing and are operating the platform I will say a few words about its commercial value. We started with gateway module simply because telematics is nothing without devices. An average software developer may face difficulties trying to connect hardware. Yes, I remember all these days, when I tried to configure my first device via serial port and another device via SMS messages. Moreover, the third device could be only configured from Windows PC, via specialized configuration software. Come on! I'm a software developer, not a technician to do all these weird things!
Believe me or not, even though we have hundreds of customers (system integrator companies) worldwide, still the most difficult phase is to connect a device. Sometimes it takes hours on Skype or even a few days for hardware specialists, just to point a device to a server! There’re so many devices, they all are so different and nowadays Chinese devices are usually number one in a test list for people, only because they are cheap. But nobody counts the time that was invested in connecting the first device and time usually costs money.
Ok, let's say we’ve pointed the device to our IP:port (yep, although not every developer nowadays has static IP address pointed to his development machine). Now you should take the protocol from the manufacturer. Chinese companies usually send dozens of files, but believe me, they are not always correct and each firmware release can have some adjustments. You can never be sure of them. Well-known brands won't send you any protocol documentation without signed NDA, but sometimes it takes weeks of communication to get it. In big companies, nobody will even talk to you until you buy hundreds of devices.
So let's say now you have the protocol. Next step is to support it. But if you are trying to support your first device, there are high chances that you will do it wrong. You can be a very experienced developer and engineer, but when it comes to telematics devices it’s like walking on a minefield. So many things can go wrong! Even if you do it right it’s highly probable that your software will be designed to smoothly work with maybe one thousand of connected devices (if you are really lucky). Because each new order of connections will put a load on your software in unpredictable places. Believe me or not.
So you did it well, everything is working, but now the manufacturer has produced a new version of the device and changed the protocol, or introduced a new chipset that is able to read more sensors e.g. CAN bus. And you are like a running monkey, now in need to support all this new in your software. This is weird and it does not allow you to concentrate on the most important thing of your software - it's primary value, it's business logic.
The idea of flespi platform is to cover all these weird things and bring you secure and reliable REST API that you can use to manage the devices. REST API is described in swagger-compatible yaml files so that you can immediately have client libraries for them on a variety of software platforms. REST API is developed such a way that you can execute very smart queries, operate over dozens of objects in one request and receive all succeeded operations in response. For failed operations we provide a full description of what was wrong.
The most important thing in the gateway is a channel. Channel is a connection point between the devices and your application. Channel has fixed IP:port that is assigned automatically by the platform during channel creation. Now it is only possible to use IP address on our location, later we will introduce more geographically distributed IP locations so that customers worldwide could even use IP addresses that belong to them. Fixed IP address is very important for a telematics backend solution because you can not change it later in a simple way, as the devices are pointed there and first you need to reconfigure the hardware. If devices don't support remote reconfiguration it is cheaper to buy and install new devices. One more important thing is that in order to prevent fake data or even DDoS attacks correct IP address and port of the channel should be hidden from the world as much as possible.
When you create a channel you specify the protocol. Protocols are now developed by flespi team using special descriptive language, and I will cover this topic later in details. We start from a number of most popular protocols, but at Gurtam we have all these established relations with device manufacturers and a large number of devices supported in Wialon. So it becomes very simple for us to support Wialon-compatible protocols. Just let us know if you need something. Eventually, we have plans to pass along this job to manufacturer engineers. The language we developed to describe the protocol is quite simple and stable, so it’s better for them to be responsible for both endpoints of the connection. But this is in the future.
So with a channel now you can point a device to it. A Channel logs all connections to it, all problems that may occur, all protocol violation errors, all bytes sent/received per each connection. So if anything goes wrong you will have a clear picture of the problem. I know this is very important for developers: we no more need black boxes, but diagnostic tools. With flespi gateway you have them all, channel logs are easily accessible via REST API and stored for the specified amount of days.
Between your application and a channel there is a message buffer. Yes, we work on the Internet where a connection can be very unstable, so you just make a request whenever you want and receive all or a part of buffered messages. The API is currently designed for a single reader mode, e.g. you can reliably retrieve unique messages only from a single reader. With each next request to the gateway, you check previously delivered set of messages and retrieve a new set. You can specify a timeout so that a server could pause your request if there are no messages in a channel and wake it up once new messages arrive. The process is simple and convenient, but anyway we will think about how to modify the API so that multiple independent readers could be used. I forgot to mention earlier, but with a single API request, it is possible to retrieve messages from multiple channels at once: simple and convenient way to work with hundreds of channels.
Gateway buffers not only incoming messages but also outgoing commands to devices. You just post to a channel, which kind of command you want to deliver, specify ident (IMEI, configurable ID or whatever used to identify the device) and then the gateway will deliver the command to the device as soon as it is connected to the channel. You can cancel the commands or check their status later as well.
At each point of time, you have a clear picture of which devices are connected to which channels, moreover you can close connections or switch them to terminal mode. Terminal mode for a TCP-connection can be used to stream raw bytes from devices to your application and back. Usually, this can be used for a firmware update or hardware configuration.
So, in the end, the main function of flespi gateway is to take away all difficulties with telematics devices communication via simple and unified REST API. Our next module will be devices registry - instead of passing traffic from channels to your application we will give you the possibility to store messages on our servers already split by the devices and sorted by time (UPD: registry module merged with the gateway module to form the telematics hub between devices and platforms). With incredibly fast access rate to messages, our target is to provide data storage system with 100.000 messages/second retrieval performance and average response delay less than 0.5 second. At the moment no cloud system on the planet with terabytes of data can do it so fast, while we can. We are already testing the database and need a few months to finalize the API, stay connected!