eStorm-L1 is a commercial off the shelf product from Embien. Loaded with many features, it is mainly crafted to support quick realization of customer requirements. eStorm-L1 has been currently deployed across industries for various functional applications.

This blog captures one of the most popular applications of eStorm-L1 as a GSM Remote Control Switch. Being based on our proven and reliable platform, the GSM remote switch brings to the industry a low cost solution and help reducing the man power. With just a SMS command to the device, multiple loads can be switched on and off. It also supports acquiring the current status of analog /digital sensors attached to it. Apart from industry applications, this remote switch can also be used for home automation purposes.

eStorm L1 – Device Information

eStorm-L1 based GSM remote control switch is a remote monitor and control device equipped with GSM connectivity and external digital IO interfaces.

Powerful MCU: The device is powered by industrial grade ARM Cortex M0+ micro-controller. It holds rich IO interface supporting multiple digital inputs and relay control outputs. The core can run at 48 MHz that is quite powerful for remote control and monitor application.

Digital Inputs and outputs: The device supports up to 4 digital inputs mainly to acquire the data from the sensor/transducers. There are option for up to 8 digital outputs in relay mode and 4 digital outputs in digital switch mode. Digital switch mode supports direct control of the load connected across the terminals whereas the relay mode supports the external relay control which controls the load connected it.

GSM Communication: The device includes dual band GSM modem with on board antenna and SIM card holder. The device supports standard 6-pin SIM card with 1.8V and 3V operating voltage.

Storage: EEPROM available in the device supports storing configurations and user account details such as user name, phone number, password etc.

Field upgrade: USB device and configuration switch is provided for field upgrade. Connecting to the PC/Laptop with the provided application and firmware will be sufficient to do the upgrade task.

Enclosure: The device is carefully designed and enclosed inside an ABC plastic enclosure to sustain under rugged industrial environment. It can be mounted on the wall through the protruded flanges in the sides of the enclosure lid.

Remote Control Switch – Operation

Device requires a valid SIM card to be inserted in the SIM card holder. User should carefully connect the load / sensors to the respective terminals. Load connected to eStorm-L1 can be controlled remotely by just sending a SMS command or a missed call for relay control. There are options for configuring one admin and up to 10 users. Only the admin has rights to add, delete the user accounts etc. Password and phone number should be valid to control the device.

Configuring the device is very simple. Just a missed call to the device will provide the administrator, a user name and password through SMS. This user name and password should be added in all the commands for valid operation and the same can be changed by the admin through SMS command. Following are the command groups and available commands that are supported by the device for remote switch application.

  1. Relay commands
    1. Group switch on/off relays
    2. Individual switch on/off relays
    3. Setting ON/OFF delay
    4. Setting ON duration
    5. Setting Relay status update option/period
    6. Setting missed call control action
  2. Inputs commands
    1. Group of inputs enable/disable
    2. Particular input enable/disable
    3. Setting ON/OFF de-bounce
    4. Setting input status update type and period
  3. Admin commands
    1. Add user
    2. Delete user
    3. Change password
    4. Change user phone number
    5. Getting user list
  4. Query commands
    1. Query device information
    2. Current relay and inputs settings
    3. Current status of inputs and relays
    4. Device network signal strength
  5. Help commands
    1. Missed call action command format
    2. Relay command format
    3. Input command format
    4. Admin command format
    5. Query command format

For all the above command types there are shortcut commands which supports easy and quick control actions for the user handling the device. Except the admin commands all the users have rights to use the commands providing a better hierarchy in control.

Following figure depicts example SMS command sent to the device and response received from the device respectively.

Example 1: Consider all relays are in off state. Issuing a command with user name and password to switch on relays connected to digital outputs 1, 3, 5, 7 at a time. The response confirmation message from the device will describe the list of relays in ON state i.e. 1, 3, 5, and 7 and the list of relays in OFF state i.e. 2, 4, 6, and 8.

Relay On command

GSM Relay On command

Example 2: Consider the relays 1, 4, 5, 8, inputs 1, 4 is ON and relay 2, 3, 6, 7, inputs 2, 3 is OFF. To get relay and input status information’s, sending query command to the device. The relay and inputs status will be sent by the device as shown in the figure upon the SMS command reception.

Status Query Command

GSM Switch Query Command

Applications of the GSM Controller

GSM based remote switch applications are generally numerous and with Embien’s device designed specifically for operating in -40 to 80 degrees, the net get even wider. Some of them include the remote control of industrial lighting, exhaust fans, engine/machine pre-heaters, cabin heaters, water well pumps, single phase/ 3-phase irrigation systems, power cycle and reboot of remote servers, routers and computers, HVAC – heating and air conditioning in holiday homes, aviation engine heaters, pumping stations, etc.

About Embien: Primary focus of Embien technologies lies in the Industrial Automation segment. We have a rich experience in working on industrial automation and control systems with customers across geographies to enable their factories and assembly lines run efficiently. Our team have developed protocol stacks for various industrial protocols and enabled them in customer devices. We have created various Human Machine Interfaces (HMI) systems to make easier the interface with the machine. Our Machine to Machine (M2M) service offering includes developing system capable of remote monitoring and controlling of machines, PLC’s, etc.

Freedom KL25Z from Freescale Semiconductor is a popular board based on KL25 ARM Cortex M0+ micro-controller. There are many tutorials and examples available for using many features of the FRDM-KL25Z board. This blog describes the implementation of USB host interface to support a low cost Bluetooth dongle along with 3-axis accelerometer and PWM features.

In the demo, an Android application will connect to the Bluetooth device connected to the FRDM board. After connection, the board will transmit its accelerometer reading to the application which will be used to render a 3D image of the board. Similarly the application can be used to drive the tri-color LED available with varying colors using PWM.
This blog will describe the hardware for the demo along with the necessary software implementation that can be customized for user’s applications such as for IoT, academics etc.

Bluetooth Stack over USB

Bluetooth connectivity for FRDM-KL25Z

Hardware Setup

Interfacing the Bluetooth USB dongle to the board is the important step for the demo. To enable using low cost devices, the demo uses low cost dongles available in local stores under 2 dollars. These devices generally uses CSR chipset module inside.

About connecting the dongle to the board, follow the procedure outlines in this MCUOnEclipse blog.

This link provides the detailed description of USB host mode hack for the FRDM KL25Z board. Another option is to modify header “J21” (Refer sheet3 in Freedom KL25Z schematics with document number SCH-27556 or SPF-27556).

For 3 Axis accelerometer support, the on-board MMA8451Q chip is used. It is connected to KL25 MCU via I2C interface. I2C0 port in pins PTE24 and PTE25 is used for the interface.

The on-board tri-color LED is utilized for PWM implementation. The Red LED of tri-color LED is connected to the PWM pin TPM2_CH0 of PTB18, Green LED is connected to TPM2_CH1 of PTB19 and blue LED is connected to TPM0_CH1 of PTD1.

S.NO Signal Name Pin Number
1 I2C0_SDA PTE25
2 I2C0_SCL PTE24
3 Red LED PTB18
4 Green LED PTB19
5 Blue LED PTD1

For this demo, the power to the board is provided through the openSDA USB Mini-B connector “J7”.


The firmware initially prepares all the underlying hardware interfaces. The USB stack first prepares the USB OTG controller for host operation. Once done, it enumerates the attached device. Once a valid Bluetooth Dongle is detected, it configures the same and brings up the various layers of the Bluetooth stack like HCI, L2CAP, RFComm etc. Once a logical channel is established between the FRDM-KL25 board and dongle, the data is transferred in a custom format.

Upon detection of change in accelerometer reading, the 3 axis data is read and sent to the Android application over Bluetooth by adding a header field in the front and footer in the end. Up on recognizing the packet, the application calculates the position and renders the 3D image of the board in the display using OpenGLES routines.

Similarly on change of LED colour values by the user, the data is send in custom frame format to the board over Bluetooth. The firmware decodes the same and drives the 3 components of the LED in different brightness values using PWM modulation.


The demo of Bluetooth Stack on FRDM-KL25Z is available as a video in the below link.

Source Code of the project

All the necessary firmware to run in the FRDM board can be downloaded from our downloads page.

With Bluetooth, especially Bluetooth Low Energy (BLE) is being used more and more in IoT applications like activity trackers, health bands etc, such a stack will be an advantage when integrating the functionality on top of USB host using low cost USB dongles.

About Embien Technologies: Embien Technologies is a leading provider of embedded design services for the Semi-conductor, Industrial, Consumer and Health Care segments. Our extensive experience in working with wireless technologies like Bluetooth, Bluetooth Low Energy (Bluetooth Smart), RFID, ZigBee, WiFi etc enables us provide solutions to customer quickly at an unmatched quality at a very low price point. Feel free to contact us for any of your connectivity, OpenGL, mobile application or embedded product development requirements.

Saravana Pandian Annamalai
21. July 2014 · Write a comment · Categories: Internet of Things, Technology · Tags: , , ,

Further to our discussion on Internet of Things, we will have a look in to one of the most promising standards proposed for IoT – LWM2M from OMA.

This post will provide a quick overview of the standards followed by a discussion on the opportunities it presents and challenges faced primarily in the object model more than the underlying communication protocols.

Light Weight M2M – LWM2M for IoT

Internet of Things presents challenges so far not seen in usual environment with known or well predicted communication and computing requirements. IoT brings in necessity to support few thousand types of devices with billions of actual devices. Further it needs even computationally less powered systems with limited network connectivity to be managed.

For these challenges, OMA (Open Mobile Alliance) a consortium of industry leaders proposed a new standard – LWM2M – Light Weight Machine-to-Machine. It is a Client-Server model and in the words used in the technical paper.

The LWM2M protocol, to be used for remote management of M2M devices and related service enablement, has at least four outstanding characteristics:

1) it features a modern architectural design based on REST appealing to software developers,

2) it defines a resource and data model that is extensible,

3) it has been designed with performance and the constraints of M2M devices in mind, and

4) it reuses and builds on an efficient secure data transfer standard called the Constrained Application Protocol (CoAP) that has been standardised by the Internet Engineering Taskforce (IETF) as a variation of the Internet’s HTTP protocol (appropriate for data transfer to and from low-cost connected IoT devices).

These words truly describe everything about LWM2M. LWM2M for IoT offers simple REST services for data logging and retrieval. It defines an Object/Instance/Resource model for data management and uses CoAP (a low-bandwidth protocol) for communication. The architecture diagram is given below.

Currently data transfer over UDP and SMS are defined with security using DTLS. There are numerous documentations and links available to describe the communication aspects of the standard and is not the scope for this discussion. Rather we will describe the data management layer.

LWM2M Object Model

LWM2M considers every device being connected to it having a set of parameters each mapped to an aspect of its functionality. Some may be Read-write that needs configuration and control and some may only be Read/Only used for observing status information.

An example might be a simple dimmer that controls the brightness of the light. The dimmer may have a variable to switch it on or off and another to set the brightness level.

LWM2M assigns a unique resource ID for each of these parameters and groups them in to something called an Object identified by a unique Object ID. For each actual device present, an instance ID is allocated which contains the actual resource values. The instance ID management is done by the LWM2M Client and typically starts from 0. There may be any number of instances based on the actual number of devices.

The example object description of a Light Control Object (object ID = 3311) will look like as follows


Resource ID




 1 5851 Dimmer Integer 0 -100 R,W
 2 5850 On/Off Boolean R,W

Considering a LWM2M Client connected to 3 Light Control objects, the client will present itself like this:

LWM2M Device Instances

LWM2M Object Instances for Dimmers

The object model and resource ID definitions may be complex depending on the complexity of the device it represents.

In terms of object/instance/resource philosophy, it resembles the CIP standard from ODVA that is employed in DeviceNet & Ethernet/IP and other protocols being used in industrial automation.

LWM2M Model – Opportunities

Now about the opportunities it presents to the IoT segment, the salient points are.

New Standard

Since being a new standard being drafted in very recent time, LWM2M is designed with IoT and M2M requirements in consideration. Backed by the expertise of OMA, it should be very easy for the LWM2M to map and accommodate the changing needs of the industry. It should be possible to create object models for the new devices being supported under IoT.


The underlying communication technology and data model is very simple and robust unlike the OMA-DM. The devices implementing this technology could even be an 8-bit system with very few kilobytes of ROM and few bytes of RAM. Further the legacy systems could be easily accommodated using simple LWM2M gateways.


With IoT industry beginning to take shape and leaders in industry like ARM, Vodafone, etc backing it, it should be very easy for the industry to accept LWM2M for IoT. With a little aggressive push, the LwM2M can find far more deployments. With reference implementations available for C and Java, developer community need not sweat it out to bring a new LWM2M device.

LWM2M Model – Challenges

Some of the opportunities we believe LWM2M have to look out in terms of its object model are as follows.

Limited defined Objects

The virtue of being a new standards is a vice here. Very few objects are currently defined. At the time of this writing, only around 18 Object IDs and 42 resource IDs are defined excluding the basic ones. A far more definitions will help in faster adoption of the standard.

On the positive side, OMA provides users an interface to request for new object definitions, which should quickly bring many devices under this standard.

Dynamic IoT Instances

Probably true to its name, LWM2M might be designed with a higher preference on M2M devices. The main difference between an industrial and say a consumer ecosystem is the relative stability and identification of devices. In an industrial setup, when a device is set up and assigned an instance, it is highly unlikely to change over time. While it might be online or off-line, the instance ID can safely assumed to be same. Whereas in a typical consumer environment, the whole system constituent may change completely. Further it is very dynamic that the order of adding a device and removing them will be chaotic. An example could be a set of Bluetooth devices deployed spread across a large area and a mobile phone acting as a LWM2M Client. With LWM2M server in the cloud, the instance orders will drastically change depending up on the range of the Bluetooth coverage. With more smart-phone clients, things will be even more complex. The following diagram depicts the difference.

Instance ID mapping for M2M vs IoT

To overcome this, a UUID – Universally Unique ID resource ID might be assigned for each device. This should be a simple version 4 UUID based on Random numbers without dependency on any governing bodies. This will provide a totally unique reference at the server and reduces dependency and complexity on the gateways.

LWM2M Gateways

LWM2M Objects connected with gateways

Further it has an added advantage of consolidating the device view. For example, in the above diagram, multiple IoT devices are connected to the main LWM2M server via multiple gateways. Ultimately the last gateway will show the devices in completely different instance ID mapping. With a UUID being used, the LWM2M can correctly select the per-registered device for control. Also it can choose use that as an endpoint to control bypassing the instance ID’s.


LWM2M is going to be a major player in IoT and we expect a lot of deployments based on LWM2M soon. When UUID is available for individual device identification and more underlying physical communication layers defined, LWM2M is sure to be here for a very long time managing the ‘Internet of Things’.

Embien, with its rich expertise in IoT and allied segments, has launched its SkyCase – IoT solution for enabling IoT for devices across industry. Combing the best in class technologies – REST, LWM2M and Java, it offers a cloud system that enables LWM2M devices to be connected and controlled. Please visit our SkyCase product page more details of the same.