Itead Studio Sonoff and Slampher: Low Cost Smart Home Solution - Review

INTRODUCTION

Itead Studio has launched a indiegogo campaign to help bring one of their new products to market. Itead Studio has been working on a WiFi enabled switch for easy home automation. They have specifically been working on two products, one that fits into a light fixture (Slampher) and one that is spliced into any cable (Sonoff). The catch behind these two products is their incredible low price (~$7 per unit) and their easy of use.

HOW I ARRIVED AT THIS POINT

I was contacted through one of my reviews on Element14 by Itead Studio concerning a new product they are looking to launch. I was asked if I was interested in reviewing a WiFi switch of theirs and to give them some feedback. As I have played around with passing data over WiFi (see my Plot.ly project) I was intrested how this may work to control something in a smart home, so I promptly responded YES! After a shipping delay the package of one Sonoff, one slampher and a 433 MHz remote were on my way.

It took a short altercation with DHL and some kind help from customs to have my package firmly in my grasp.

INITIAL SETUP (NO INSTRUCTIONS)

Having arrived on a Thursday I decided to wait for the weekend to try everything out as I figured it may take some time to look into everything that interested me about this product. When I did start to play with the units I decided to start without looking at any instructions, if I can get most. if not all the way through using a product then I’m willing to keep going with it. I started by downloading the app from the Google Play store and tried from there to get something started. In all to get the slampher working took 5 minutes without instructions, for some unknown reason the Sonoff took a bit longer but eventually it worked as well. The next step was to get the 433 MHz remote working. With some fiddling around the Lamphor connected to button A on the remote but there was no way I was getting the Sonoff to connect to button B. After trying various more things and figuring the unit was a bust I decided to read the instructions… It didn’t take more than 30 seconds after doing that to connect the Sonoff to the remote's button B.

SETUP WITH INSTRUCTIONS (THE CORRECT WAY)

The correct procedure, this time following the instructions would be:

If you would like to simply turn on/off your device without using the remote or app then you can quickly press the “set” button on slampher/sonoff once to do so.

Pair with 433Mhz RF remote controller without WiFi .

1. Press the “set” button on Sonoff and Slampher twice quickly and the red LED on Sonoff/Slampher will flash one time.
2. Now press button “A”, ”B”, ”C” or ”D” on the controller to pair with the remote. If you pair it with “A”, then pressing “A” will turn on/off your device.
3. If you would like to remove the pairing, press the"set" button on Sonoff/Slampher quickly 3 times.

APP Operation

1. Download and install the app on your smartphone
2. Register a new account, you’ll need to enter your phone No. and password (at least 8 letters, must contain number, lowercase and uppercase letters). A code will be sent to your phone via SMS, enter the verification code to register.
3. Login with your account.
4. Add devices.

1. Before adding a device, you must turn on the WiFi on your phone, then press and hold the “set” button until the green LED indicator blinks quickly.
2. In the app click “+” to add devices followed by “Start searching”, it will auto-search and connect the “ITEAD10000xxx” WiFi around you.
3. Then select your WiFi account and enter password, click remember so that next time you don’t need to fill in again.
4. Click “next” to name your device, then “next” you will add the device successfully.

Note: If you see the new added device is offline, please wait for a moment. If it keeps offline, please power off the device, then power it up, if everything is ok, it will become online.

5. Delete devices - If you would like to remove a device, you need to go to the devices list, then slide the device name from right to left. You will see the delete icon, just press it to delete your device.
6. Manage Group - Click the top right corner button on device list interface. You’ll see”Manage Group””Exit Account””Exit e-Welink”. Click “Manage Group” to add or delete group. After adding group, you can long press to select the device and move it under your group. If you delete a group, the devices belong to this group will still exist.
7. Share devices - Enter the device you want to share, click icon “share” then enter the Phone number you want to share with, this phone No. should register and login first and remain online. That number will then receive an invitation message, by accepting the invitation, that user will have the authority to control the device you share. Only the owner of the devices has right to share devices.

e-WeLink APP

The app packs a lot of functionality even if it may be in its initial stages of release. The first feature that is very much appreciated and may be taken for granted is the status update. Whenever the status of the device is changed, the app will reflect this change. That is, if a shared user changes the status or someone uses the remote or if someone presses the button on the device directly, any of these changes will be reflected in the app. This quickly and easily allows a user to know the status and change it and verify that change if needed.

Another nice feature is the timer feature, considering a basic timer will run you ~$20 this is one big deal. There are a number of timers that can be set (the exact number is untested at this point). But not only can a timer be set once or repeatedly but, there is a countdown timer as well. This is a nice feature for someone leaving their house or getting ready for bed. The timer could be set to turn off the light after a specified amount of time without the need to remember to do so once you have left the house or gone to bed.

As this is an app on a smartphone it would not be complete if it was not possible to share control with another user. This too has been included and is easily done. Once shared the other user can easily turn on and off the device and use it the same as the main user. For this feature it would be nice if in a future release of the app if the level of control could be chosen so that a secondary user could not remove timers or maybe could only turn on/off a device but not the other way around.  

Itead has definitely thought of this as a large scale project in that they are hoping that you will deploy this across many locations, to make this easier they have introduced groups A group allows a user to put all devices, say in their home, in one group so that finding the standing lamp in your dining room will be relatively easy without needing to go through all the devices at the cottage, office, etc.

Overall the app is intuitive and very easy to use. Itead has kept the user interface simple and clean allowing for a great user experience, and with fast update times on a device's status change the app keeps you always informed as to what your devices are doing.

Power Consumption

One of the things that concerns me about using a device that is always plugged in is the ongoing power consumption. The idea here is partly to reduce power consumption and potentially save money. I was therefore wondering what the power consumption of the Sonoff was. It should be noted that currently there is nothing to compare this value to but hopefully in the near future this will be added.

As can be seen in the graphs below the power consumption appears to be sitting below 1 Watt for half of the duration and above 1 watt for the remainder. It should be noted that the blips that exceed these values are when the unit was on and powering a fluorescent lamp.

Figure 1. Power consumption measured in watts

Figure 2. Current measured in amperes

Figure 3. Voltage measured in volts

The issue here is the overall cost of having a unit connected all the time if there was away for Itead to reduce the overall power consumption this would make for an even better product.

That being said there are two HUGE factors to take into account regarding my measurements. The first is I was using two multimeters logging at one second intervals to a laptop over bluetooth and this may not provide the best results. If the unit only wakes up every 200 ms and is on for 20 ms to listen for WiFi or 433 MHz signals the power savings would be tremendous but the multimeters would not see that and report a higher than real power consumption. The second issue is the lack of comparable data, without anything to compare my measurements too only a small fraction of the data is being shown. For this to be useful I would need to take measurements on other time switches as well as other comparable devices, such as those from Belkin. In a later post I will try look at a time switch to be able to at least give another data point.

Figure 4. Setup used to measure voltage and current to arrive at power consumption

I am hoping to look more into the power consumption as well as some of the irregularities that can be seen in the first half of the graphs in a later blog entry. I would also like to look into what the power consumption is of both the sonoff and the slampher in relation to other timing/standby products to get a better understanding of how the efficiency of these products compares to other such products.

CONCERNS

After working with this product for a few days I have tried a few different things and feel I have enough basic experience to give my feedback both positive and some less so. Starting with the less so, I would say the app needs some work. Currently the network password for your home network is stored in plain text and is always available I have been assured that this will be fixed in a later release of the app and is a “known issue”. It would also be nice if I did not have to go into each individual light to see its state but rather if the entry page could display that information directly.

Figure 5. Itead app home page

The next concern I have is the longevity of the unit. Since all the units only work through Itead’s servers, should this fail for some reason all the units would no longer be useable unless someone else decided to take that on or if Itead would make all their code publicly available. Currently I do not see this as an immediate issue as Itead appears to be taking this product very seriously

Lastly is the issue of form factor, both the slampher and sonoff could be more discreet. The slampher adds a decent amount of length to the average light bulb preventing this from being used in a closed light fixture or any fixture that may have a length limit. As for the sonoff the form factor is pretty good, but one person noted if it could be smaller it could be inserted in light or socket fixtures. Maybe the real solution to that is for Itead to increase their product range by offering a light switch or conventional plug. Overall I did not have any issue with the sonoff other than a possible missing connection point for a ground wire connection when using a three prong plug.

Figure 6. Sonoff with two connection points

POSITIVES

For Itead’s offerings the positives outweigh the cons. Firstly it should be noted that the price point per unit for Itead’s system is significantly less than that offered by the competitors, at ~$7 per unit or ~$22 for 4 units the cost is very low.

The next positive is ease of use, the simplicity in the units setup and control make it easily usable by anyone on any level of technical knowledge. The clean interface in the app allows for easy and quick control of any device be it in your home network or in another location network. The overall system also adds a decent amount of convenience as well as security with the ability to remotely turn on lights and well as check their status remotely. This would be great for someone coming home late and would like to have their home illuminated before entering either for comfort or security. This system would also allow for light to be turned on should motion be detected somewhere or a noise heard without the need to go to that location.

I also found the design of both units, while maybe cumbersome in form, easy to you. The slampher simply fits into an existing light fixture and then a bulb is inserted into it. While the sonoff has two connection points and is agnostic as to how the wires are connected. This allows for anyone to connect a device by splicing the wires with only the need to ensure they keep each wire going in connected to itself at the exit. While I have not checked that both wire are disconnected when the sonoff is turned off, I would imagine that this would be so to ensure the end device (lamp, fan , etc.) is not live with only the ground wire disconnected.

These devices potentially also have the ability to reduce power costs as the devices can be turned off remotely. This means if a light/device was left on or may have been left on the app can be checked and if indeed the light/device was indeed left on it can be turned off remotely thus saving power and money.

MOVING FORWARD

I have chosen to further support Itead’s campaign buy buying 4 Slamphers for use around the home. I have done so for a few reasons. Firstly the level of support I have received shows that there is active development and knowledgeable people behind this development. Secondly, I have samples in hand this shows that they have something that works that is ready for feedback and lastly Itead is a functioning and thriving online store. This would imply they have both the knowledge and ability to bring this product to fruition. While there may be some concerns, overall I believe it is relatively small payout for a potentially amazing and growing product.

Indiegogo Campaign

https://www.indiegogo.com/projects/sonoff-slampher-low-cost-smart-home-solution/#/

Blog on standby Power

http://goughlui.com/2015/12/23/standbyno-load-power-consumption-are-we-doing-it-right/

Other Blogs On Itead Slampher & Sonoff Reviews (in no specific order)

http://matthewcmcmillan.blogspot.ca/2015/12/product-review-itead-studio-wifi.html?showCom

ment=1450703164942

http://blog.brianmoses.net/2015/12/sonoff-and-slampher-home-automation-review.html

http://misc.ws/2015/12/11/itead-studios-smart-home-switches/

http://electronicopensource.blogspot.ca/2015/11/itead-sonoff-wifi-wireless-switch.html

http://www.cnx-software.com/2015/12/03/sonoff-slampher-are-5-rf-and-wifi-smart-switches-and-lightbulb-adapters-crowdfunding/

http://nfriedly.com/techblog/2015-12-16-itead-sonoff-slampher-review/

https://giovanniorgantini.wordpress.com/2015/12/22/home-automation/

Original post on Element14 can be found here

My Own Dreamboard: FRDM-KL25Z Motion Data Logger Using MBED

Introduction

Element14 has been running a competition for a DreamBoard and I was wondering how available some of the setups people are requesting are, to work this out I decided to do a simple project. The project goal was to use an ARM processor and incorporate a few sensors and store the data. After looking around I decided to go with the FRDM-KL25Z development board from Freescale and use the FRDM-STBC-AGM01 add on board. As there was no easy way to add an SD card I created my own board for that and at the same time added a battery monitoring circuit to make it a true stand alone unit. All the code was written using mbed to better feature the ARM processor on the FRDM-KL25Z.

Usage Case

The idea behind this project originated from two usage cases with essentially the same basic idea. As I work on equipment that needs to be ruggedized both from the elements as well as from handling, I thought what better way to understand what the equipment goes through than to log it. Its one thing to be told that something needs to stand up to rough handling and abuse but, if that abuse can be quantized it makes designing for the worst case that much easier. The second case and somewhat similar is shipping of fragile packages. It is possible to attach fragile stickers and shock sensitive glass vials but that would only tell you that a threshold force was reached but not for how long or how often or even when during transportation. An active motion logger would resolve all these unanswered questions. Both of these use cases would allow for the use of the FRDM-KL25Z with just one or two add on boards keeping the system simple and as close to a Dreamboard design as possible

Project Goal

Following these two usage cases mentioned above it was important to understand the main goals that this project setou to achieve. As both cases are looking at the handling of an object over a relatively short period of time (1 ~ 8 days) battery life was not critical, a custom battery/SD card board was built but that was mainly because it wasn't until later I found the Freedom Battery Charger Expansion Board. The custom board follows the design of the TI Fuel Gauge BoosterPack but with updated components. Another aspect of the project was price, as it is not known what the units are really exposed to in terms of  abuse, keeping the cost low would mean a damaged or destroyed logger would be no real concern in terms of replacement. Along the lines of a damaged or destroyed unit is the issue of data loss, should an event happen to cause a logger to be destroyed that event should, as much as possible, be recorded. Lastly the project should be implemented quickly and kept simple so that any issues that may arise or any requirement changes should be easily dealt with by anyone capable of understanding simple hardware/software.

Data Acquisition and Volume of Data

Looking to log data for 1 ~ 8 days without missing any abusive handling there was a need to establish how fast the system could sample data and store it without losing any of that data. It was decided by a pseudo scientific method that 50 Hz sample rate should be adequate. This was reached by assuming a falling object from one foot or so would take approximately 0.247s to fall, using 50 Hz would give approximately 10 data points on the way down allowing for an approximate drop height to be calculated as well as the force the unit experienced on impact (depending on the surface)

The accelerometer can log data in either 14 bits or 8 bits. Assuming higher resolution and therefore 14 bits that needs 6 bytes of data per sample or 300 bytes per second. The gyroscope also can log data in 8 or 16 bits and again using the higher resolution gives us 300 bytes per second. Since I2C can be set to run at 375 kHz, this would give a data transfer time of ~6.4ms. The I2C bus was eventually set at 400 kHz with a realistic clock frequency of 375 kHz.

Once acquired from the sensors, the data is stored on a SD card for later analysis.The SD card is written too using the SPI protocol which can achieve a theoretical 40 MHz. After some testing it was determined that the realistic speed for the FRDM-KL25Z programed using mbed was only 1 MHz, while very much slower than the 40 MHz desired it posed to be no issue for the setup. Using an 8Gb SD card the unit would be able to log data for ~154 days or well after the batteries are no longer working. This is estimated from 300 bytes/s for each sensor(8Gb / 600 bytes/s / 60s / 60m /24h = 154.32).

The battery life for this project is estimated to be 5 days using a 1200 mAh battery and the full power run current of 7.1 mA for the FRDM-KL25Z, 35 μA for the FXOS8700CQ sampling at 50 Hz and 2.7 mA for the FXAS21002CQR1. This gives a total current consumption of 9.835 mA and for a 1200 mAh battery that gives ~122 hours or ~5 days, if low power mode was implemented for the FRDM-KL25Z this could be further extended. This does not account for SD writes or other components on the boards.

Hardware Setup

The hardware consists of of three PCBs. The first board is the FRDM-KL25Z that contains the MKL25Z128VLK4 that is the brains behind the system and has the bootloader for the mbed environment.

Figure 2. FRDM-KL25Z Development Kit from Freescale

The second board is the FRDM-STBC-AGM01 this board houses the two sensors used in this project, the FXOS8700CQ is a 3 axis accelerometer and magnetometer and the FXAS21002CQR1 is a 3 axis gyroscope. The sensors both use the I2C and SPI protocols to communicate with the host processor. Since there are limited number of SPI modules on the host processor and the data rate of the sensors is relatively low the I2C module was selected. Another reason for this choice is the FRDM-STBC-AGM01 is configured for I2C and the the FXOS8700CQ only works with point to point SPI.

Figure 3. FRDM-STBC-AGM01 Sensor Board from Freescale

The last board is an SD card connector breakout board like the DIGILENT  PMODSD  PERIPHERAL MODULE or the MIDAS  UNO32-SD  DAUGHTER BOARD. The board used in setting up this project was a breakout board from 43oh which was replaced by a custom board* that was designed specifically for the FRDM-KL25Z.

Figure 4. Custom PCB Layout with Space for Both a SD Card & Battery Monitoring

The design of this boards borrows from the TI Fuel Gauge Boosterpack. The circuit is the same except for the BQ27510-G2 which has been upgraded to the G3. While the software for the BQ27510-G3 has not yet implemented when completed this will allow for the system to be truly stand alone and take precautions to ensure all data is saved before the battery is about to die.

Figure 5. Custom Board with SD Card & Battery Management Circuit

Figure 6. Custom Board with SD Card & Battery Management Circuit

While there is a expansion board from Freescale that has similar abilities, specifically the FRDM-BC3770-EVB, this board does not contain a SD Card slot and this board was only discovered after the custom board had be sent to the fab. The custom board includes both card detect and write protect pins to allowing the host controller to be sure there is an SD card available and in a usable state before starting the system.

Figure 7. System Implementation Using Three Separate Boards

Software Outline

The software was written in a simple and easy to understand style to allow for anyone wanting to read over the or modify the code to be able to do so. For this reason the code follows a very simple progression as will be outlined below. The code was written in the mbed environment allowing for further simplification, at each stage in the flow diagram for the software there is some code that demonstrates what is required at that stage of the software flow. The full program can be found in the mbed repository here.

This project uses interrupt driven programming, this means that all events in the main loop only happen after an interrupt routine has set a flag signaling for the main loop to take action. Both interrupts that are used are fired when a sensors has recorded a preset number of samples in its FIFOs. When the interrupt occurs it sets a flag letting the mainloop know that there is data to be fetched from that sensors FIFO.

Figure 8. Interrupts That Drive the System

The first step in the code is to include the two libraries that are needed, mbed.h adds the basic functionality for the chosen platform and SDFileSystem adds the functionality for writing data to the connected Sd card. Once the needed libraries have been added, the registers used by both the FXOS and FXAS sensors are defined, this allows us to keep later I2C calls simple and self explanatory. The next step is to initialize the needed system modules.

Looking at the flowchart below we see the first module that is initialized is the serial port. This port is mainly used for debugging as it is a relatively slow port and in mbed serial communication is a blocking operation, it is therefore not desirable to use the serial port during high speed data acquisition. I2C is initialized to enable communication with the sensors and at a later stage the battery monitoring IC as well. The I2C port used is port PTE pin 0 for the data line (SDA) and pin 1 for the the clock (SCL).

Setting up the interrupts is a two step process, first we set pins to be interrupts in this project, pins PTD4 and PTA5 are set as FIFO full interrupts from the two sensors. The second step with regards to interrupts is done in the main function and that is to assign what to interrupt on (high -> low or low -> high transitions) and when an interrupt occurs what function should be called. In this case both interrupts are happen on a rising edge and they call functions called fxas_data and fxos_data respectively.

The last step in the initialization before going into the main function is to set up the Sd card communication. This is done by creating a SDFileSystem object and then giving that object the pins used for MOSI,  MISO,  SCLK and CS. In this project the default SPI port was used, PTD2, PTD3, PTD1 and PTD0 respectively. It has been verified that it is possible to use other SPI ports but for simplicity only one is pointed out on the platform pin descriptions.

After the initializations are completed the I2C clock frequency and serial baud rate are increased to allow for faster communications and reduced interruptions. For this reason the SDFileSystem used in this project has been modified to increase the clock frequency to 1 MHz to prevent the system from losing data during a SD card write cycle. The next step is to create a directory on the SD card in which to place or data and a file with heading. The last step in the main functions initializations is to set up and start the sensors, this is done by calling fxas_init() and fxos_init(). Once all these steps have been completed the system will start logging data.

Figure 9. System Initialization

The main loop runs in the background and does all the heavy lifting. The first step in the main loop is to look for a FIFO full flag set in one of the two interrupts. Once a flag has been set the main loop will read all available data samples and store them in a local buffer. This buffer was arbitrarily set at 23, for better performance and possibly longer sleep times by the processor this could be set to 30 or 32 samples. When all the samples have been read from the sensor a data ready flag is set, this flag indicates to the next step of the main loop that data is ready to be sent to the SD card.

After data from both sensors has been read in, which should happen very close in time as both sensors are running at 50Hz, the main loop will send all available samples to the SD card. To do this correctly and in somewhat of a understandable fashion the MSB and LSB of each sample are concatenated before sending the data to the SD card. As the accelerometer data is 14 bits long and the LSB is left justified, there is a need to first shift the MSB left by 8 bits then OR the two bytes and finally right shift  all 16 bits by two to arrive at 14 bits of data. As fractional operations are  computationally heavy on microprocessors multiplying the data by either 0.976mg or 7.8125mdps has been left to be completed on the PC.

Once all data has been sent to the SD card the file is closed, this is done once every 30 cycles to ensure minimal amounts of data are lost. It is not done more frequently as this adds extra overhead to the SD write cycle. After closing the file the buffers are cleared, while not essential this was done to remove any question as to the correctness of the sampled data.

Figure 10. Main Loop Where the Time Consuming Operations Occur

The software in its entirety can be found here, the project can be added to your project space and then downloaded to your own FRDM-KL25Z from that location.

MBED

As part of this project was to show of the ARM core at the center of all the processing, the mbed environment was used. Along with showing of the ARM core mbed also allows for implementing programs in relatively simple and quick ways to be used as a prototype or in some circumstances for get to the final product quickly. While using mbed for this project I realized the ease with which other wise long and complex tasks can be achieved. Setting up interrupts and along with what action should be taken when fired only takes two lines. Similarly setting up the SD file system also takes two lines of code.

That being said there are some thing to watch out for. During this project I was not able to use the blue LED for debugging, this was discovered only after I was no longer able to save data to the SD card. It was later noticed that the SD card clock and the blue LED are on the same pin. Other issues where setting clock frequencies. The clock for the SPI but does not appear to be able to be set above 1 MHz, while I have tried a few different ways to reach this I was not able to do so. The same issue is noticed with the I2C bus, going above 375 kHz does not appear possible, I was hoping to achieve 400 kHz but setting the frequency higher only seems to decrease the clock frequency after a certain point.

Also not having a built in debugger when you are used to depending on one is a huge change in the game. Another big change that may take getting used to is the bootloader. Where with a conventional IDE there is a one step compile and program, here there is a two step compile and download and then drag and drop into the platform. While not a huge game changer it does slow down the programing iterations. Both of these may have bothered me but in a weird way I feel doing more programing like this would make you a better programmer as there is a need to do this better and in a more thought out manner the first time and less by trial and error.

With a few issues encountered along the way there is one very big positive to mbed. There is a large and very helpful community. No matter how big, small or subtle the issue I found that the community was both willing and very capable of helping.

Project Testing and Usage

The project while on a basic level is complete this is room for further progress. At this point there is a need to use the project to log how a package that is shipped is handled so as to better understand the design constraints to build a resilient outer shell.

In order to use this unit in a somewhat meaningful way the data obtained from this project is put through a graphing program to determine how the unit has handled. My program of choice is GNUPlot or Excel. While Excel has a limitation on the number of points it will plot for you (1048576) GNUPlot does not. Below I have included data samples from some test with this project to give an idea of what the project is capable of.

Figure 11. Accelerometer Data Recorded on a 15 Minute Drive

Figure 12. Gyroscope Data Recorded on a 15 Minute Drive

Issues experienced and their resolutions

Pin mapping and peripheral usage

FRDM-KL25Z not capturing Interrupts

Non-blocking interrupts

Arithmetic or Logical Shift in mbed

SDFile system working in standalone but not with other code

Logical operator frustrating me

FXAS21002 Not Generating Interrupts

Odd behaviour with F_STATUS register FXOS8700C

FXOS8700 data appears very noisy

*Rev A of the board is on branch Board_Inverted and not on the main branch at this point in time.

Original post on Element14 can be found here