Most recently, in the device presentation of the Smilio Action Multiservices, you could find out what kind of device this is, which use cases you can implement with it and what significant advantages and limitations it has. As announced, in this second article we now deal with the activation, assembly and configuration of the Smilio A.
With regard to activation and assembly, it is advisable to first activate the device and then assemble it at the destination.
You can also find precise step-by-step instructions for activating the device in the Smilio A manual, but we have briefly summarized the most important steps for you:
Before you start the actual activation, you have to make sure that the device has been made known to the LoRaWAN® or Sigfox network you are using and that it has been created in the corresponding system. For example, this can be our Minol ZENNER Connect LoRaWAN® network using the B.One Middleware.
If you want to use the Smilio A with Sigfox, you can skip this step. If, on the other hand, you want to use it with LoRaWAN® like we do, you have to remove the so-called "jumper" before inserting the batteries, which is located in the housing next to the battery compartment (see photo below). To remove it, simply pull it upwards (Tip: this works best with small pliers or something similar, as it is difficult to grasp the jumper with your fingers alone).
Now all you have to do is insert two 3.6 V AA Lithium Thionyl Chloride batteries (it is recommended by the manufacturer to only use this type of battery) and close the battery compartment with the screws provided.
After inserting the batteries, the boot process starts automatically, what can take a few minutes. Depending on whether or not the configuration is changed when the device is switched on via a valid downlink payload, the LEDs at the end of the boot process either light up green or red for three seconds (for details, see the manual). Another sign that your Smilio A has been successfully activated and is connected: green lighting up of the LEDs after pressing a button.
When it comes to assembly, it depends very much on what exactly you are using the Smilio A for and where it is to be attached. There are the following options for attaching the box: loose installation using the anti-slip pads on the back, wall mounting using an additional bracket or attachment to a so-called display or poster bracket (sold separately), for example, to provide explanatory content in addition to the device at the destination. Here are a few examples to illustrate:
As far as the configuration options of the Smilio A are concerned, you basically have the option of choosing between different operating modes and changing other parameters if necessary. In the following we will first take a closer look at the changeable parameters and modes and then how you can change the configuration.
In addition to the operating mode, a number of other parameters can be changed. Here is an overview of the parameters that we believe are relevant for "normal" users, including the respective default values upon delivery:
|Parameter||Description||Default value at delivery|
|dtx||Time span between two transmitted data packets in periodic transmit mode 0 (adjustable via parameter "eat", see below)||15 (minutes)|
|tpb||Minimum time span between two button triggers||3 (minutes)|
|tpbq||Minimum time interval between two magnetic card detections||3 (minutes)|
|csc||Fine adjustment Periodical transmission mode for energy saving: 0 = after each interval a data packet is sent independent of the counter value - 1 = only if counter value has changed compared to the previous one, a data packet is sent||1|
|rnm||Selection of operating mode: 1, 2, 3, 4, 6, 7, 8 or 9 (see below for detailed explanation in each case)||2|
|eat||Selection of transmission mode: 0 = Periodic transmission, i.e. data packet is sent every "dtx" (see above) minutes - 1 = Immediate transmission, i.e. data packet is sent after each button press with the "tpb" delay - 2 = Dual transmission mode, i.e. combination of 0 + 1||1|
A complete list and explanation of all parameters can be found in the manual.
Let's take a closer look at the operating modes (parameter "rnm", above). A total of 9 modes are available to you to adapt the Smilio Action Multiservices to your particular application.
During the "tpb" delay (see above) the following applies:
Example: If you press button 1, you can only press a button again after 3 seconds.
During the "tpb" delay:
Example : If you press button 1, you can also press the other buttons within the "tpb", but only once each.
During the "tpb" delay:
Here, during the "tpb" delay:
Example 1: if you press button 1, you can also press buttons 3, 4 or 5, but not button 2.
Example 2 : if you press button 2, you can also press buttons 3, 4 or 5, but not button 1.
Since there is no mode 5 in the manual, it goes directly to mode 6.
Mode 6 basically corresponds to mode 2 (see above), except that in this case the device expects a confirmation from the network server after pressing a button. This verifies that the payload sent was also correctly received by the server (also called "confirmed uplink payload" or "acknowledgment payload"). If the Smilio A has successfully received the confirmation from the server, the LEDs light up green. Red otherwise or after a 60 second timeout. The keyboard is locked until the confirmation is received or until the timeout has expired and it is only then possible to press the buttons again.
This mode basically corresponds to mode 9 (see below), only that analogous to mode 6 (see above), after pressing a confirmation from the network server is expected.
This mode basically corresponds to mode 2 (see above). The difference is that after each data packet sent, i.e. after each press, the counter is reset to zero. This means that pure button states can be transmitted without measuring the triggering frequency.
This mode is used, among other things, to enable identification of a person, proof of presence, entry and transmission of codes or confirmed codes and detection of the use of magnetic badges. To do this, the buttons 1,2,3,4 and 5 do not increase their respective value after being pressed, but allow the creation of a user code by shifting it to the left with each press (maximum 6 digits, if there are more digits only the first 6 digits are saved).
In order to trigger a confirmation, the Hall effect sensor integrated in the device must be activated in this mode, for example with a magnetic ID card.
Under normal conditions, a countdown will start as soon as the first key press is detected. The seconds value of this countdown is equal to "tpb". The user enters his identification code (maximum 6 digits). If the user does not activate the magnetic sensor before the countdown ends, the code will not be validated, otherwise the code will be validated. At the end of the countdown, the " tpb" LED will turn green to inform the user that a new code can be entered.
If you want to familiarize yourself a little more with the difference between the normal modes, the PULSE and the CODE mode, then it is also worth taking a look at the Smilio Action Simulator. Here you can simulate pressing the buttons and see how the counts for each button behave depending on the mode.
Now that you know which configuration options are available to you, we want to go into how exactly you can change the configuration. For a better understanding, we will first take a look at the basic structure of the Smilio A payload, i.e. the content of a data packet sent from or to the device, using an example.
Regardless of the transmission mode selected, thenormal default payload format when the device transmits is as follows, with the transmitted counts all being in hexadecimal:
02 AAAA BBBB CCCC DDDD EEEE
02 = Standard payload
AAAA = Incremental count value button 1 → Example: 0001 hexadecimal = 1 decimal
BBBB = Incremental count value button 2 → Example: 0010 hexadecimal = 16 decimal
CCCC = Incremental count value button 3 → Example: 00A0 hexadecimal = 160 decimal
DDDD = Incremental count value button 4 → Example: 0023 hexadecimal = 35 decimal
EEEE = Incremental count value button 5 → Example: 0010 hexadecimal = 16 decimal
Please note: as can be seen above, in the version of the Smilio A Multiservice used here, the button numbers printed on the device unfortunately do not correspond exactly to the numbers or blocks of numbers stored in the payload. The button with the imprinted 3 corresponds to button 4 (DDDD), the button with the imprinted 4 to button 5 (EEEE) and the button in the middle with the imprinted smiley button corresponds to button 3 (CCCC).
In addition, we would like to point out that the payload format can of course differ from the one listed here, depending on the mode set (see manual).
Every time the device is switched on or a user presses the reset button, a so-called "downlink query" payload is sent with the currently stored settings. The format here looks like this:
04 UU VVVV WW XX YZ TT
With regard to the following explanations, it should be said at this point that you should not be confused by the other parameters such as the "duty cycle". We won't go into detail about these and haven't listed them above, as we believe they can be safely ignored by normal users. For all others we refer to the manual again.
04 = "Downlink Query" payload
UU = "csc" and "eat" hexadecimal values (transmit mode and operating mode)
0x00: Device transmits at every period end, independent of counter readings
0x10: Device transmits at each period end only if counter values have changed
0x01: Device sends at each actuation with a delay of "tpb" between two actuations
0x02: Device sends at every actuation with a delay of "tpb" between two actuations + every "dtx" minutes (backup function), independent of the counter values
0x12: device sends at each actuation with a delay of "tpb" between two actuations + every "dtx" minutes (backup function), if counter values have changed
VVV = hexadecimal value to be converted into the bit field 'abcdefffffffff'.
a: duty-cyle (0 = disabled, 1 = enabled)
b: LoRaWAN backoff (0 = disabled, 1 = enabled)
c: LoRaWAN piggyback (0 = disabled, 1 = enabled)
d: LoRaWAN force DR0 at join procedure (0 = disabled, 1 = enabled)
e: LoRaWAN ADR bit (0 = disabled, 1 = enabled)
fffffffffff: dtx expressed in minutes, 11 bit values from 0x0001 to 0x05A0.
WW = "tpb" hexadecimal value (in seconds) from 0x01 to 0x3C.
XX = "rnm" Hexadecimal value from 0x01 to 0x09
YZ = "Lwf" Hexadecimal value from 0x00 to 0xFF
TT = "Lwf" Hexadecimal value from 0x00 to 0xFF
After sending the Downlink Query payload, the device waits for a Downlink Result payload with new settings from the backend. You can use this to ultimately adjust the configuration of your Smilio. The format of this payload is the same as the Downlink Query payload, except that it starts with 05 instead of 04:
05 UU VVVV WW XX YZ TT
To make it easier for you to create a valid downlink payload, Skiply provides you with the practical web application Smilio Configurator. Here you simply select the desired values for the individual parameters using dropdowns and at the end you receive the appropriate payload, which you can save to the clipboard with Ctrl + V for storage in your backend system.
All you have to do now is store the created "Downlink Result" payload in your backend system in order to be sent to the device when the "Downlink Query" payload is received. As described above, this happens as soon as the device is switched off and on again or reset via the reset button. You can see how easy it can be in the blog post “Sending downlinks using B.One Middleware”. Important: With this device, you must always specify port 2 as the port for a "Downlink Result" payload.
You now also know how to activate, assemble and configure the Smilio Action Multiservices. Soon you will find out which LoRaWAN® use case we have implemented with our Smilio A, how we proceeded and what our conclusions about the experiences with the device are at the end.
So be curious and stop by again :-)