how to build your IoT dashbord with Sigfox

 

Man use smart home automation in living room with digital tablet and mobile app : Stock Photo

SIGFOX is a solution that targets disconnected devices. On SIGFOX your device can send between 0 and 140 messages every day. This is really a max of one message every 11 minutes if you want a distribution. And each message could be up to 12 bytes of real payload data. You might also transmit 4 messages of 8 bytes payload to every device every day. In order to receive messages, the device needs to request from the server, which means that it has to be programmed to receive data in events or at situations.

 

The protocol transmits the apparatus ID, therefore the 1 2 and 8 bytes reflect the payload and there’s absolutely no limit on what you are able to structure the payload. SIGFOX completely change or does not understand your payload, only you realize how it is ordered.

 

The demands are readily covered by 1-2 bytes for devices which transmit data such as the positioning of an alert, a power consumption indicator, a device clock, or another kind of sensor details that is basic. The 8 bytes sent to devices enable you to send configuration data if needed, should you not need communications by simply being one-way but you may maximize battery life.

 

How to use Sigfox (Uplink) with thethings.iO

The Sigfox back-end can automatically forward several events utilizing the”callback” system. The Callback system allows you to make use of a thethings.iO call-back URL that enables thethings.iO back-end to get the Sigfox apparatus messages. This permits you to take advantage of those thethings.iO features like analytics, cloud code, and interoperability, etc..

 

Callbacks’ configuration is done inside the device page.

The callbacks are triggered whenever a device message has been received or when a computer device communicating loss has been detected.

 

A callback has a set of variables:

 

  • device: device identifier (in hexadecimal – up to 8 characters <=> 4 bytes)
  • data: the user data (in hexadecimal)
  • others: time, duplicate, snr, station, data, avgSnr, lat, lng, rssi and seqNumber

Next is an example of the callback configuration form with only device (id) and data (data)

How to configure thethings.iO to use Sigfox

thethings.iO backend has to be configured to manage a Sigfox device. Follow the next steps:

Create a new product

You have to create a new product and choose Sigfox as a Serialzation Format.

Get the subscription URL

Once you have created a Sigfox product, click on the product to get the subscription URL that you have to use as a callback URL at the sigfox backend.

This URL only gets the device and data variables. If you need other values like time, duplicate, snr, station, data, avgSnr, lat, lng, rssi and seqNumber; you have to include a key value for each one at the URL query. By default only device and data are added.

Parse the Sigfox Payload

When you create a new sigfox product, a function with the name ‘sigfox_parser’ is automatically created. You have to edit that function and insert the code that parses the sigfox payload. Please, don’t change the name of this function. Any name other than ‘sigfox_parser’ will not work.

You get the Sigfox deviceId (device) and the payload (data) from the params parameter. You can access both with params.deviceId and params.data

function main(params, callback){

    var result = [

    {

        “key”: “temperature”,

        “value”: parseInt(‘0x’+params.data.substring(0,2))

    }

    ]

    callback(null, result) 

}

To access to the other values (time, duplicate, snr, station, data, avgSnr, lat, lng, rssi and seqNumber), you have to use: params.custom.time, params.custom.duplicate, etc.

You can also geolocate your device to be displayed on a map with the lat and lng values. You have to store this values at the $geo key.

/*

  You can preview this function with this preview params:

  {

    “deviceId”: “00F2302”,

    “data”: “20”,

    “custom”: {

      “rssi”: 1.2,

      “lat”: 41.41,

      “lng”: 2.17

    }

  }

  

  If you use Postman, you have to set this body:

  

  {

    “id”: “00F2302”,

    “data”: “20”,

    “rssi”: 1.2,

    “lat”: 41.41,

    “lng”: 2.17

  }

 

*/

 

function main(params, callback){

    var result = [

    {

        “key”: “temperature”,

        “value”: parseInt(‘0x’+params.data.substring(0,2))

    },

    {

        “key”: “rssi”,

        “value”: params.custom.rssi

    },

    {

        “key”: “$geo”,

        “value”: [params.custom.lng, params.custom.lat]

    }

    ]

    callback(null, result); 

}

As a result you have to return an array of objects with this structure:

[ {“key”: temperature, “value”: 21}, {“key”: humidity, “value”: 50} … ]

Sigfox Custom Payload

If you use the Custom payload config option, you can access that data too. At this example Temp and Humi resources are defined. To access them at the cloud code function you can do this:

var temperature = params.custom.Temp 

var humidity = params.custom.Humi

Sigfox Errors

When you get a 500 Internal server error or a 600 response timeout, you have to check the next steps to find where or why is this error. Our api returns an error message if something goes wrong, but the Sigfox backend doesn’t show this error message, only shows a 500 internal server error.

  1. Check if your subscription plan is expired
  2. Check if you have exceeded your monthly api calls rate.
  3. Check if you have reached your devices limit.
  4. Check if your sigfox_parser function exists and is working properly. Use postman to simulate a call.
  5. Check the resource sgfx-error of your device. There are stored some errors from the sigfox_parser code.
  6. Check if the data that your device sends is at the sgfx-payload resource, and this data is correct.

 

Leave a Reply

Your email address will not be published. Required fields are marked *