I just read the article https://www.losant.com/blog/how-we-built-the-poc-asset-tracker
It mentions the gateway that needs to be deployed to a public accessible server.
Do I need to set that up or is that something you have up and running?
It’s not something we provide out-of-the-box, but it is something we do deploy and manage on behalf of customers for an additional fee.
If you choose, you can also certainly deploy the gateway to your own server that is managed by your team.
Is there any further documentation for that gateway?
There’s no further documentation, however that repo could use a readme.
At a high level, it’s converting the @Track Protocol, which is used by most of the Queclink asset trackers, to Losant’s MQTT protocol.
The reason it requires a gateway is because you simply point the tracker to a raw IP/Port and it connects and sends data using essentially raw TCP. The gateway runs on a small, dedicated, vm in the cloud, which provides that dedicated IP/port to connect to.
Could you explain the rationale for creating three types of devices mentioned in the article? Do we need a gateway device to minimize the impact on the platform limits?
Thx
@Brandon_Cannaday couldnt this separate server be avoided by going with a particle asset tracker with direct particle/losant integration? unless im missing something particles electron asset tracker also has the ability to be extended w other vehicle inputs & controls vs quelink
The Particle tracker is perfect if you’re evaluating the Electron as part of a custom tracking device/solution. For the POC kits, we wanted an off-the-shelf tracker with a nice enclosure and optimized for battery life.
We also wanted to present something that a customer could immediately put into production if they chose. The Queclink trackers are FCC/CE certified. While the Electron board is certified (which helps a lot), you also have to certify the end result with the enclosure, battery, and everything.
The Electron tracker is meant to be used as an internal POC when essentially developing your own version of a Queclink tracker. When you want to sell the tracker commercially, you’d have to go through certification with the final product.
Makes sense excellent points thanks
Hi Brandon, are you able to provide a setup guide/instructions for the Server?
Can the server be setup on Losant using http request/response endpoints?
Most of the Queclink trackers support SMS transmissions, so the easiest approach would be to use Twilio’s Programmable SMS as a bridge between the tracker and Losant.
Tracker -> SMS -> Twilio -> Webhook -> Losant
This architecture eliminates the need for any additional server infrastructure.
Here are two guides that show how to receive SMS messages from Twilio:
You’ll receive the raw @Track message in the resulting webhook message. Most trackers will be similar, but you’ll have to refer to the documentation for the specific tracker to see what fields are supported.
Thanks @Brandon_Cannaday.
I’m currently making API calls to the manufacturer’s server platform to access device state in my application. I was looking to untether from the manufacturer and still use API calls.
Ah, I assumed you were talking specifically about Queclink trackers, which do not support HTTP.
If your devices can already send data over HTTP, then I’d recommend sending the data directly to a Losant Webhook.
If you require more control over the receiving API endpoint, you can also look at Experience Endpoints.