Skiply provides industrial solutions. Therefore, we can not afford to loose any customer data. LPWAN networks like Sigfox and LoRaWan are great. But, like any radio communication system, a frame can be corrupted or not transmitted. If you do not take this into consideration in your design, and send only "pulses", if it happens, you will loose data.

This is why we decided to provide a system that is robust enough to support bad or missing radio frames. Each time that a user presses a button, the corresponding index is incremented. Thus, depending of the parameters that you set on your device, the system will send the data at periodic interval, or a few seconds after an action. The application server will receive this state, and calculate the increment since last transmission. Even if a frame has been lost, the total number of buttons pressed will always be found.

Thanks to this method, we can also send thousands of votes each day, for instance for the satisfaction use case, despite the 140 messages limitation / day of the LPWANs.

From an intergration point of view, it seems to be more complex. This means that you have to store the last index values in a database (or persistent variable). If you do not feel confortable with that, we can provide an api that will make this job for you.

A pulse mode is available, but we do not recommand to use this mode in production.

It depends on how you bought your Smilio Action.

If you bought the product without any service

You must subscribe to a LPWAN operator. It can be Sigfox, or any LoRaWan ready network (Orange in France, Machine-Q in the US, etc.). You will have to provision your device with the PAC code (Sigfox) or with the provided keys / id (LoRaWan).

Alternatively, you can use your own private LoRaWAN network. To make your connected buttons work, you need to provision the device on your Network Server (Orbiwise, Actility, TTN, etc.)

If you bought the product with the api service

We push the data directly to the endpoint that you gave us at the order.

In order to register your connected buttons Smilio Action on the Sigfox Network, you may require to enter the End Product Certificate.

It is: P_0056_99E6_01

Please find attached the full certificate.

To install and ensure correct operation of your Smilio Action, please read carefully and follow the instructions contains in this user manual :

• For Smilio Action bought from August 1st, 2019 (FW 2.0.1.4) : Download
• For Smilio Action bought from September 21st, 2018 to July 31st, 2019 (FW 2.0.1.x) : Download
• For Smilio Action bought before September 21st, 2018 (FW 1.19) : Download 

Principle

• Each LPWAN operator sends data with different formats and/or protocols (REST, MQTT, Pub/Sub…): the SPA delivers a standard json payload to your server. It always remains the same, independently from the Network Operator (Sigfox or LoRaWAN). Therefore, it acts as a high level roaming system.
• The SPA decodes the data whatever the Running mode / frame is (pulse, count, code, battery level), taking into consideration the version of your device’s firmware.
• The SPA does the annoying job for you: calculation of the increments, checking the data consistency, and eliminating “bad frames”.
• We POST data to the URL of your choice (you can include API key as parameter or custom header). See the Skiply API documentation to know how to manage this parameters.

Frame details

The buttons are numbered as follow: 

• Button1 = top left
• Button 2 = top right
• Button 3 = middle
• Button 4 = bottom left
• Button 5 = bottom right

> Push API: normal mode

{
  "device": "SA000272",
  "groupId": 5,
  "time": "2018-06-21T20:14:31.394Z", // ISO 8601 date
  "sq_num": 98,
  "frameType": "02",
  "data": {
    "index": [1,0,16,1,2],
    "increment": [0,0,0,0,2],
    "button_1": 0,
    "button_2": 0,
    "button_3": 0,
    "button_4": 0,
    "button_5": 2,
    "ack": 0
  },
  "negativeValue": 0,
  "rawPayload":"02000100A2000000000003"
}

Where:

• device = serial number of the product
• groupId = group of the device. Can be usefull to facilitate to consolidate device data, for instance in the context of live visualisation
• time = timestamp from the network
• sq_num = frame sequence number, to identify if a frame has been missed
• frameType = "02" or "03" (with ack)
• ack = 1 if the frame has been send due to a magnetic detection instead of normal operation (badge)
• index = state of the internal counters : [button1, button2, ... , button5]
• increment = variation of the index between to frames received by our servers : [button1, button2, ... , button5]
  code = type of frame
• negativeValue = return 1 if a negative increment has been detected (reset). Increment is [0,0,0,0,0] in this case to avoid bad counts
• rawPayload = payload receive before decoding

> Push API: code mode

{
  "device":"SA000272",
  "groupId": 5,
  "time":"2022-06-21T20:14:31.394Z", // ISO 8601 Date
  "dc_delay": 0,
  "sq_num": 98,
  "frameType": "11",
  "data": {
    "code": "021214",
    "increment": [2,2,0,1,0],
    "button_1": 2,
    "button_2": 2,
    "button_3": 0,
    "button_4": 1,
    "button_5": 2,
    "ack": 0
  },
  "previous": {
    "code": "012334",
    "increment": [1,1,2,1,0],
    "button_1": 1,
    "button_2": 1,
    "button_3": 2,
    "button_4": 1,
    "button_5": 0,
    "ack":1,
    "previous_time": 13,
    "missed":true,
    "estimated_time":"2022-06-21T20:01:31.394Z"
  },
  "rawPayload":"11000100A2000000000003"
};

Where:

• frameType = "11" or "13" or "31" for code mode
• dc_delay: potential delay from the Duty Cycle protection in minutes
• data: code entered by the user
  • code: value of the code (1 to 5, max. 6 digits)
  • increment (button 1 to 5, number of presses per button)
  • ack = 1 if the code has been validated by magnetic detection (badge)
• previous: code entered previously by the user
  • previous_time: time since last code what entered (in minutes)
  • missed: returns yes if we detect that this previous frame was not received by our server (for instance due to bad network conditions)
  • estimated_time: estimated time of the previous frame

> Push API: keep alive (sent every 24h)

{
  "device": "SA000272",
  "groupId": 5,
  "time": "2018-06-21T20:14:31.394Z", // ISO 8601 Date
  "sq_num": 99,
  "frameType": "01",
  "data": {
    "battery_level": 3.35
  },
  "rawPayload":"010EC640EC64"
}

Where:

• device = serial number of the product
• time = timestamp from the network
• sq_num = frame sequence number, to identify if a frame has been missed
• frameType = "01"
• ack = always 0 for this frame type
• battery_level = in volts
• code = type of frame

Retry

The Push API will send data to the endpoint defined in the group configuration, and wait for a 200 code in return. If the system doesn't receive a 200 response, a new try will be done after 60 seconds. If the retry fails, an error is logged with the missed data and error code returned.

Path is perfect if you are afraid to write code. But you can spare a lot of steps in your zap using the "Run Javascript" Action in Zapier.

Let's take an example. The following code in the "Run Javacript" Action will change the message depending on a combination of buttons pressed:

if ((inputData.button1 == "1") && (inputData.button3 == "1")) {
    output = {message: "Nettoyage demandé"};
} else if ((inputData.button2 == "1") && (inputData.button3 == "1")) {
    output = {message: "Rangement demandé"};
} else if ((inputData.button4 == "1") && (inputData.button3 == "1")) {
    output = {message: "Vider les poubelles"};
} else if ((inputData.button5 == "1") && (inputData.button3 == "1")) {
    output = {message: "Urgence"};
} else if (inputData.badge == "1") {
    output = {message: "Demande traitée"};
} else {
    output = {message:"void"};
}

The following action (for instance a SMS with Twilio) will be able to use the new "message" variable generated by this script.

If you want to change the destination number for each device, you can use the Google Sheet lookup action, using a variable "Action" to retrieve the correct number.

if ((inputData.button1 == "1") && (inputData.button3 == "1")) {
    output = {message: "Nettoyage demandé", action: "action1"};
} else if ((inputData.button2 == "1") && (inputData.button3 == "1")) {
    output = {message: "Rangement demandé, action: "action2"};
} else if ((inputData.button4 == "1") && (inputData.button3 == "1")) {
output = {message: "Vider les poubelles, action: "action3"};
} else if ((inputData.button5 == "1") && (inputData.button3 == "1")) {
    output = {message: "Urgence", action: "action4"};
} else if (inputData.badge == "1") {
    output = {message: "Demande traitée", action: "action5"};
} else {
    output = {message:"void"};
}

There are several ways to use the magnetic badge. One of them allows to discriminate "confirmed service requests", using the magnetic badge, from "non confirmed service requests". for instance, a confirmed request could be considered as an urgent request.

To do that, you should use the code mode (RNM 9 in the documentation):

• The user has TPB seconds to press one or several buttons corresponding to his request, calculated from the first push.
• If a badge is used before expiration of TPB, the radio frame is sent immediatly, with ack = 1 (Skiply API) or a raw payload beginning with 0x03 (direct integration).
• If no badge is presented before the expiration of TPB, a frame will be sent with ack = 0 (Skiply API ) or a raw payload beginning with 0x02 (direct integration).

The entire list of parameters to be set to implement this use can can be found on the Skiply configurator.

This video shows how to register a Smilio Action connected button to the LoRaWan network TTN (The Things Network).

How you can use the headless CMS Directus with Smilio Action to create a very efficient app to manage the field services.

In order to help you to set your device depending on your use case, you will find hereunder a few
standard configurations. All acronyms are defined in the user manual that has been sent to you by
email.

We recommend that you read it carefully before changing the default configuration of your
Smilio Action.

All the configurations presented hereunder are made with :

• Backoff = 0
• Duty Cycle = 1 (use 0 only for test on private networks)
• Piggyback = 0
• Lwf = 0x00
• Force DR0 at join = 0 (use 1 in combinaison with ADR = 0 if you want to always use SF12 for maximum radio power)

You can use the configurator for advanced or customized configurations: https://skiplyfrance.github.io/configurator.html

Should you need any further information, do not hesitate to contact our support department:
support@skiply.org

Smilio Action Cancellation / Validation

Parameters values

• Running Mode 1 = a single push permitted among all buttons and on the same button during “TPB”
• TPB = 5 seconds
• EAT = 1 (immediate sending)

Downlink payload

• 0501800105010005 (ADR OFF)
• 0501880105010005 (ADR ON)

 Smilio Action Multiservices

Parameters values

• Running Mode 2 = a single push permitted on each button and on the same button
  during “TPB”
• TPB = 5 seconds
• EAT = 0 (periodic sending)
• CSC = 1 (periodic sending only in case of counter change)
• DTX = 10 (periodic sending: every 10 minutes)

Downlink payload

• 0510800A05020005 (ADR OFF)
• 0510880A05020005 (ADR ON)

Smilio Action 3 Smileys

Periodic sending every 15 minutes

Parameters values

• Running Mode 1 = a single push permitted among all buttons and on the same
  button during “TPB”
• TPB = 5 seconds
• EAT = 0 (periodic sending)
• CSC = 1 (periodic sending only in case of counter change)
• DTX = 15 (periodic sending: every 15 minutes)

Downlink payload

• 0510800F05010005 (ADR OFF)
• 0510880F05010005 (ADR ON)

Periodic sending every 30 minutes

Parameters values

• Running Mode 1 = a single push permitted among all buttons and on the same
  button during “TPB”
• TPB = 5 seconds
• EAT = 0 (periodic sending)
• CSC = 1 (periodic sending only in case of counter change)
• DTX = 30 (periodic sending: every 30 minutes)

Downlink payload

• 0510801E05010005 (ADR OFF)
• 0510881E05010005 (ADR ON)

In the case you manage your devices network connection and you want to push back data to our servers  to access our services, it is necessary to configure a callback of data from your operator to our servers.  

The configuration is done from your operator backend, by declaring/registering the routing endpoint to our servers (HTTP POST request).

NB: If you manage different types of devices on your backend, please configure your routing so that only data from Skiply devices is sent to our servers!  

According to your operator:

• Live Object: Data menu, then Routing. Use “Message filters” to limit data routing to Skiply device
• Objenious: Connection menu, then Routing scenarios and click on “Create a new scenario”. Use Groups to limit data routing to Skiply devices
• Sigfox: use the device types and the configuration of their “Callback”

For provisionning in TTN or Chirpstack, you will need to create a device profile.

LoRaWAN MAC version must be 1.0.2 and regional parameters must be A

For provisionning in TTN or Chirpstack, you will need to create a device profile.

LoRaWAN MAC version must be 1.0.2 and regional parameters must be A

Skiply provides industrial solutions. Therefore, we can not afford to loose any customer data. LPWAN networks like Sigfox and LoRaWan are great. But, like any radio communication system, a frame can be corrupted or not transmitted. If you do not take this into consideration in your design, and send only "pulses", if it happens, you will loose data.

This is why we decided to provide a system that is robust enough to support bad or missing radio frames. Each time that a user presses a button, the corresponding index is incremented. Thus, depending of the parameters that you set on your device, the system will send the data at periodic interval, or a few seconds after an action. The application server will receive this state, and calculate the increment since last transmission. Even if a frame has been lost, the total number of buttons pressed will always be found.

Thanks to this method, we can also send thousands of votes each day, for instance for the satisfaction use case, despite the 140 messages limitation / day of the LPWANs.

From an intergration point of view, it seems to be more complex. This means that you have to store the last index values in a database (or persistent variable). If you do not feel confortable with that, we can provide an api that will make this job for you.

A pulse mode is available, but we do not recommand to use this mode in production.

To remove your Smilio terminal from a vertical support, you have to be equipped with a thin and robust cable (iron wire or fishing line). 

Unroll a sufficient length to tighten the wire and pass it behind the device (start on the top of the box). Then, make lateral moves (back and forth movements) in order to saw the resin located between the wall and the Smilio terminal.

Repeat the movement until you have completely removed the terminal from its adhesive part (ensure that it does not fall at the end). 
If there are still some traces of adhesive on your wall, they can easily be removed with a clean cloth and surgical spirit. (90° of alcohol).

Watch our video:

Principle

• Each LPWAN operator sends data with different formats and/or protocols (REST, MQTT, Pub/Sub…): the SPA delivers a standard json payload to your server. It always remains the same, independently from the Network Operator (Sigfox or LoRaWAN). Therefore, it acts as a high level roaming system.
• The SPA decodes the data whatever the Running mode / frame is (pulse, count, code, battery level), taking into consideration the version of your device’s firmware.
• The SPA does the annoying job for you: calculation of the increments, checking the data consistency, and eliminating “bad frames”.
• We POST data to the URL of your choice (you can include API key as parameter or custom header). See the Skiply API documentation to know how to manage this parameters.

Frame details

The buttons are numbered as follow: 

• Button1 = top left
• Button 2 = top right
• Button 3 = middle
• Button 4 = bottom left
• Button 5 = bottom right

> Push API: normal mode

{
  "device": "SA000272",
  "groupId": 5,
  "time": "2018-06-21T20:14:31.394Z", // ISO 8601 date
  "sq_num": 98,
  "frameType": "02",
  "data": {
    "index": [1,0,16,1,2],
    "increment": [0,0,0,0,2],
    "button_1": 0,
    "button_2": 0,
    "button_3": 0,
    "button_4": 0,
    "button_5": 2,
    "ack": 0
  },
  "negativeValue": 0,
  "rawPayload":"02000100A2000000000003"
}

Where:

• device = serial number of the product
• groupId = group of the device. Can be usefull to facilitate to consolidate device data, for instance in the context of live visualisation
• time = timestamp from the network
• sq_num = frame sequence number, to identify if a frame has been missed
• frameType = "02" or "03" (with ack)
• ack = 1 if the frame has been send due to a magnetic detection instead of normal operation (badge)
• index = state of the internal counters : [button1, button2, ... , button5]
• increment = variation of the index between to frames received by our servers : [button1, button2, ... , button5]
  code = type of frame
• negativeValue = return 1 if a negative increment has been detected (reset). Increment is [0,0,0,0,0] in this case to avoid bad counts
• rawPayload = payload receive before decoding

> Push API: code mode

{
  "device":"SA000272",
  "groupId": 5,
  "time":"2022-06-21T20:14:31.394Z", // ISO 8601 Date
  "dc_delay": 0,
  "sq_num": 98,
  "frameType": "11",
  "data": {
    "code": "021214",
    "increment": [2,2,0,1,0],
    "button_1": 2,
    "button_2": 2,
    "button_3": 0,
    "button_4": 1,
    "button_5": 2,
    "ack": 0
  },
  "previous": {
    "code": "012334",
    "increment": [1,1,2,1,0],
    "button_1": 1,
    "button_2": 1,
    "button_3": 2,
    "button_4": 1,
    "button_5": 0,
    "ack":1,
    "previous_time": 13,
    "missed":true,
    "estimated_time":"2022-06-21T20:01:31.394Z"
  },
  "rawPayload":"11000100A2000000000003"
};

Where:

• frameType = "11" or "13" or "31" for code mode
• dc_delay: potential delay from the Duty Cycle protection in minutes
• data: code entered by the user
  • code: value of the code (1 to 5, max. 6 digits)
  • increment (button 1 to 5, number of presses per button)
  • ack = 1 if the code has been validated by magnetic detection (badge)
• previous: code entered previously by the user
  • previous_time: time since last code what entered (in minutes)
  • missed: returns yes if we detect that this previous frame was not received by our server (for instance due to bad network conditions)
  • estimated_time: estimated time of the previous frame

> Push API: keep alive (sent every 24h)

{
  "device": "SA000272",
  "groupId": 5,
  "time": "2018-06-21T20:14:31.394Z", // ISO 8601 Date
  "sq_num": 99,
  "frameType": "01",
  "data": {
    "battery_level": 3.35
  },
  "rawPayload":"010EC640EC64"
}

Where:

• device = serial number of the product
• time = timestamp from the network
• sq_num = frame sequence number, to identify if a frame has been missed
• frameType = "01"
• ack = always 0 for this frame type
• battery_level = in volts
• code = type of frame

Retry

The Push API will send data to the endpoint defined in the group configuration, and wait for a 200 code in return. If the system doesn't receive a 200 response, a new try will be done after 60 seconds. If the retry fails, an error is logged with the missed data and error code returned.

Path is perfect if you are afraid to write code. But you can spare a lot of steps in your zap using the "Run Javascript" Action in Zapier.

Let's take an example. The following code in the "Run Javacript" Action will change the message depending on a combination of buttons pressed:

if ((inputData.button1 == "1") && (inputData.button3 == "1")) {
    output = {message: "Nettoyage demandé"};
} else if ((inputData.button2 == "1") && (inputData.button3 == "1")) {
    output = {message: "Rangement demandé"};
} else if ((inputData.button4 == "1") && (inputData.button3 == "1")) {
    output = {message: "Vider les poubelles"};
} else if ((inputData.button5 == "1") && (inputData.button3 == "1")) {
    output = {message: "Urgence"};
} else if (inputData.badge == "1") {
    output = {message: "Demande traitée"};
} else {
    output = {message:"void"};
}

The following action (for instance a SMS with Twilio) will be able to use the new "message" variable generated by this script.

If you want to change the destination number for each device, you can use the Google Sheet lookup action, using a variable "Action" to retrieve the correct number.

if ((inputData.button1 == "1") && (inputData.button3 == "1")) {
    output = {message: "Nettoyage demandé", action: "action1"};
} else if ((inputData.button2 == "1") && (inputData.button3 == "1")) {
    output = {message: "Rangement demandé, action: "action2"};
} else if ((inputData.button4 == "1") && (inputData.button3 == "1")) {
output = {message: "Vider les poubelles, action: "action3"};
} else if ((inputData.button5 == "1") && (inputData.button3 == "1")) {
    output = {message: "Urgence", action: "action4"};
} else if (inputData.badge == "1") {
    output = {message: "Demande traitée", action: "action5"};
} else {
    output = {message:"void"};
}

The public Sigfox coverage map is available here: https://www.sigfox.com/en/coverage

This map is usefull, but not as detailed as the one available in the Sigfox backend (service maps), where you can see the number of gateways available in the area and the margins:

 Skiply offers to its customers the possibility to check the coverage for a single GPS coordinates thru the API. 

Request:

https://skiply-prod.appspot.com/v1/getSigfoxCoverage?lat=:lat&lng=:lng

Result:

HTTP/1.1 200 OK
{
  "outdoorCoverage": 3,
  "indoorCoverage": 1,
  "bestMargin": 32
}

Where:

• outdoorCoverage = number of gateways covering the area (outdoor).
• indoorCoverage = number of gateways covering the area (indoor).
• bestMargin = best margin in dB.

For provisionning in TTN or Chirpstack, you will need to create a device profile.

LoRaWAN MAC version must be 1.0.2 and regional parameters must be A

For provisionning in TTN or Chirpstack, you will need to create a device profile.

LoRaWAN MAC version must be 1.0.2 and regional parameters must be A

Follow our video...

Follow the video:

Ubiqod is a traceability platform.

With Ubiqod, you can connect any Skiply device, but also QR codes (static and dynamic) to third party systems likes monday.com, Microsoft Power Automate, Zapier or Google Sheet.

Ubiqod is a self-service platform, which means that you can open a free account and test it by yourself without the need to contact us. A button simulator is included in order to let you test the system without having to deal with the constrainst of real buttons.

If you need to plug your buttons to the platform, you will have to contact your Skiply reseller.

Ubiqod is suitable for users looking for nocode system to build their own App with connected buttons or QR codes.

When you build a configuration downlink with the Skiply configurator tool, you get a payload that looks like: 0510901E05010005

To send this downlink directly to a device connected to Helium network from your Helium console, you first need to convert this hexadecimal payload into a Base64 string.

To do that, you can use this tool: https://base64.guru/converter/encode/hex

In our example, 0510901E05010005 (in hexa) will become BRCQHgUBAAU= (Base64).

Then, enter this payload into the downlink tool in the console:

Be very carreful to enter PORT 2.

After adding the downlink to the Queue, you have to wait for the device to send a data frame. If the configuration changes, the device will reboot and join again to clear past configuration.