Inspired by the true story…
As a GPS hardware manufacturer, you are constantly working on delivering reliable service to your clients. However, it’s not always easy to feel in your client's shoes and quickly evaluate the reported issue. We in flespi want to help you stay in close touch with your clients, see the problem with their eyes, and monitor the raw and parsed dataflow in real-time.
Below are the schemes and explanations of how you can use the flespi platform as a connectivity and debugging tool for your business, deliver quality service, and build credibility.
Case 1. Your client IS using flespi
Configuring the infrastructure
You provide a bunch of GPS trackers to send data to the client target platform. And you want to be able to track issues along the way and respond to them ASAP. A thin but dense flespi middle layer will help you be in control of all data transfers.
You’ll need a proxy channel first. This type of channel allows forking the raw dataflow from the GPS tracking devices to up to three targets (platforms).
The first target is your client’s channel accepting messages from your devices. It's absolutely transparent for the client — all the data will arrive as if directly from the trackers.
The second target is your channel accepting messages from these same devices. You don't have to direct it anywhere — it's needed for debugging purposes.
Debugging & troubleshooting opportunities
The above scheme, although simple, gives a number of opportunities to figure out what’s going on with the data.
Dealing with raw data
Proxy channel features a built-in tool for sniffing raw data — HEX Viewer. With it, you can see all the raw packages coming from each tracking device, all the events, and the actual HEX payload of each message.
Dealing with parsed data
With each flespi channel comes the possibility to see its detailed logs and messages via Toolbox. Since your second target is the flespi channel working over your protocol, you can monitor the connection status, connects and disconnects, errors, message parameters in real-time and history modes.
Debugging commands
Proxy channel configuration allows transmitting replies from the target to the channel's input connection. Switching “Proxy Replies Back” option on for your channel instead of client’s channel enables you to use Toolbox to check how commands arrive:
Looking with the client’s eyes
If for some unknown reason you can not reproduce the behavior your client is reporting, check what he has for yourself.
Ask the client to generate an ACL token for you to access their flespi account and check Toolbox for their channel(s). It’s enough to grant GET /gw/channels and GET gw/protocols for that:
Once you get this token from a client, you will have access to their Toolbox at the following link:
https://toolbox.flespi.io/#/login/<--your-token-goes-here-->
You will be able to see the exact logs and messages they have (which is what you need).
Case 2. Your client is NOT using flespi
This scenario is simpler, more generic, involves fewer elements, but also has fewer debugging options. The receiving client platform can be any application ready to accept and parse the incoming telemetry messages — flespi will only serve as a debugging tool for you (the hardware manufacturer).
You’ll still need to create a proxy channel in flespi. This time the dataflow will transit through flespi into the client destination platform without forking. The only target is the IP:port of the client’s application awaiting the GPS data.
With this scheme in place, you can use the HEX Viewer in the proxy channel to see the raw messages coming from your devices right before they depart for the client's app thus giving you a perfect chance to catch and debug troublesome situations.
***
As you see, building a relatively simple chain you get plenty of options to analyze any arising situations: from and to devices, in raw and parsed format, with your and your client’s eyes.
Use the power of flespi to your benefit, exceed expectations, promote your business to the new level.