Thursday, 28 April 2016

One Year with Pebble (Time): a user and a developer perspective

The smartwatch "revolution" didn't happened as expected by the industry.

The sales numbers tells that Samsung, Google or Apple have conviced enough people.
Smartwatchesare perceived like new toys, instead of useful things and, often the disadavantages of having one are more than the advantages:
- ridiculous battery life
- no killer apps
- ridiculous apps (sending hearths or drawing to someone...)

and they are also expensive.

(Another interesting review from engadget about apple watch one year on)

With a lot of skepticism, last year I decided to buy one, just to understand the potential of these devices in everyday life.

Since, I found frustrating to charge my watch every night, I decided to become a bacher of the new pebble time, because it guarantees (in some conditions) 7 days of battery life, display always on, waterproof, and imho it is designed as a watch first, instead of a wrist-phone.

I'm not a typical smartwatch user.. not the one for who a smartwatch is designed for.
A smartwatch is useful if it can cover some microtasks related to "TIME" like:
- calendar notification
- alarms
and it is important that if it can work most of the time without the dependency from the smartphone.

I don't care about app notifications, neither of app integration.
I like the possibility to develop my own apps and expand watch functionality with apps.

BTW, an honorable mention is for the stock Health app, it tracks my daily sleep and daily steps: it is an addictive functionality and useful.

I use the smartwatch also in the sea, during surf sessions and this is a plus, because I can leave my phone inside the bag on the beach and receive call notifications.

Watchfaces are a nice idea, to change the look to the device but, you have to choose wise if you want to preserve battery life, because some "cool" watch faces can drain your battery faster.

Developing a WatchApp: "Work Time"
One thing I do when I arrive at work, it is to keep track of the arrival time: in order to calculate when I can leave the office.
This is a repetitive task and it can easily covered by my pebble!

I developed an app "Work Time" that vibrates when it is time to go home.
Create an app for a limited device it is an interesting challenge: inputs, cpu, memory, screen are limited.

Work Time is composed by these screens:
- Estimated Exit: It show you at what time you can leave
 

The app is configured using these 3 screens in sequence:
- Check In: the time of the arrival. Default is the current time.
- Work Time: how much time you work
- Break : how much time is your break


When your settings are done, you can close worktime, it will notify you with a vibration when you can go home and a screen like this one:
 

The pebble documentation is better than other platform I developed for... but creates a watchapp for pebble is not that easy due to:

- small community around the subject
- hard debugging: logs based
- cloud.pebble.com: online based editor and sdk.. sometimes it is a limit
- C language: good for optimization, bad for complexity


Btw, if you are interested, the code for WorkTime is here: https://github.com/crazycoder1999/worktime

Saturday, 28 November 2015

When an ESP8266 encounter MQTT and an accelerometer

This is a project I built for a presentation at http://milan2015.codemotionworld.com/ on November 21st.
This idea use ESP8266 (esp04), Nodemcu, MQTT and an accelerometer (adxl345 / sparkfun) by I2C.
It is an IOT project.
This project started as a "drone project" but the original idea changed during time.. by the way, helped me to do:
  • some experience with MQTT and I2C
  • see how much I can push the Esp8266
It was an interesting challenge!
Check the slides on my previous post to learn more about the project.
In my final demo I had:
Feel free to write me if you want to repeat the project and need helps.


Tuesday, 24 November 2015

ESP8266 and IOT talk at Codemotion Milan 2015

I was a bit far from the blog.. but it was because I was preparing a talk for

I built a demo using nodemcu, esp8266, mqtt, mosquitto, nodejs and adxl345.
Shortly: reading raw data from accelerometer (x,y,z) and send that data with MQTT through wifi.

More info coming veeeery soon..with sourcecode!

Wednesday, 22 July 2015

My adventure with ESP8266 (2/2): flash it!

Introduction 
The first part is here and it is about:
  • hardware
  • software
  • firmwares
  • nodemcu
It contains important information to understand this part.

Wirings
This table show how to connect the hardware together:


Pay attention to GPIO0, you need it connected only for flashing.

Flashing!
It's time to flash the device with a new firmware using esptool.
I decided to flash a nodemcu firmware.
Connect the GPIO0 to GND and than power on the device.
On my installation on OSX I did this command to flash the device:

python esptool.py -p /dev/tty.usbserial write_flash 0x00000 nodemcu_21072015.bin

If everything is ok, you should see this message:


Power off the esp8266 than remove the GPIO0 connection and than power on the chip again.

Talk with ESP8266
Now, it's time to talk with the chip.
I use kermit with this .kermrc configuration:

set carrier-watch off
set line /dev/tty.usbserial
set speed 9600

than you can press "c" to connect and typing print ("hello"); you should see the device responding hello back.
Now you can test some commands.

If you have downloaded the luatool, you can write your programs in a text file with lua extension and upload on the board with

python luatool.py --port /dev/tty.usbserial --src main.lua --dest main.lua --baud 9600

Lua files
Now, you can connect to the esp8266 and type dofile("main.lua"); to run the program.

If the file you are loading on the device, it is called init.lua the esp8266 at every boot will load it: pay attention, a bad init script can block the device forever... The only solution in this case is a re-flash of the device.

If you have any question, feel free to ask in the comments section.
If you like the article please share it! :)

my wirings :)



Tuesday, 21 July 2015

My adventure with ESP8266 (1/2)

Introduction
This article will explain all the steps I did to succesfully use the ESP8266 chip.
The ESP8266 is a an incredible low cost chip (< 5$!) to enable wifi communication for your project.
It is capable of:
  • create a wifi network: a wifi hotspot
  • connect to existing wifi hotspot
  • programmable digital pins: with I2C or SPI support!
I think this is ideal for many IOT project, at least in a prototype stage.
The chip is pretty new but thanks to its "open" nature and its cost, there are already some alternative firmware available.
This guide is tested for OSX Yosemite, but you can find similar tools also for Linux and Windows.
You can find different variants of ESP8266, but I think this tutorial will work equally with all the versions.

My version is the "04":
isn't it too cute ??? :D

My Hardware
  • CH340G USB to Serial (TTL) converter
  • ESP8266: I have the version 04
  • A stable 3.3v power with enough ampere to power the chip: I used a step down converter from 5V to 3.3V, the LM2596 calibrated with a multimeter and connected to a 5V/2A phone charger
  • a computer
Software
  • driver for CH340G here
  • kermit-c or any serial terminal software (minicom for example). For OSX
  • a firmware to flash: read below
  • esptool.py here
  • luatool here: valid only with nodemcu firwmare
Firmwares
The default firmware of the chip can be outdated.
This firmware exchange data with AT command on serial line.
A list of commands is here, but commands can change in every firmware.
This firmware is good if you need to connect the ESP8266 to other components (for example an arduino).
My esp8266 comes with a firmware not capable of talk with AT commands in any f*****g way, it started as an hotspot (see image) but I was not able to talk with at any serial speed.

BTW, the hotspot check is a good way to control if the ESP8266 is correctly connected


I flashed a new updated version of the official firmware.
The default firmware is splitted in 4 .bin files: I have to power off and than power on the chip after each flash.
I than tested the AT command with kermit-c, pressing CTRL+J in the terminal after every typed command.
As far as I know, It is possible to create custom programs using the EspressIf SDK and C++.

NodeMCU
I decided to test another firmware and the choice was the nodemcu firmware.
This firmware lets you write scripts in LUA language; it's a new language for me, but the syntax is pretty simple.
The advantage here are:
  • upload scripts, without reflashing the firmware
  • the availability of a powerful and simple API with a good documentation

[the second part is available here]

Monday, 15 June 2015

Android + Gradle: Build different APKs with different dependencies

Introduction
Recently, I switched my projects, to Android Studio.
Two years ago when Google announced the new IDE, I was skeptic: android studio was buggy and gradle a new complicated tool to learn.
Today I'm an happy user of android studio.

In this tutorial, I will talk about my experience with gradle and some useful customization I made on the build process of my app, called Qoffee.

The problem
Qoffee is available on Play Store and Amazon App Store and allows users to find the best coffee in town.
One of the last features I added, it was the support for Android Wear: now it is possible to search coffees from the smartwatch!

With the new features:
- the new apk is passed from 1.2 mb to 3.9 mb
- the new apk contains also the apk to install into the smartwatch
- there is a new Service, precisely a WearableListenerService. This service is the one that talks with the watch.

New classes/features were not useful on the apk for other app store (eg. amazon).
In the new solution, it is now possible to automatically build 2 separate apk:
- one for play store: with all the features (size: 3.9 mb)
- one for other store: without android wear and google play services support (size: 1.2 mb)

Remove unused files: Separate the Code and merge manifests
I searched a way to create 2 different builds for my app, in order to create a custom Manifest and to remove the WearableListenerService from the non-play store apk.
In the src folder of my project on android studio I created 2 new “Java Folder”:
- playstore
- genericstore

Create a new Java Folder


New project tree


The original folder for my project was called “main”.
I created 2 other AndroidManifest.xml files, and placed them in the new folder playstore and genericstore like this:
- AndroidManifest.xml in main folder contains common data for both apk: eg. all the common activities
- AndroidManifest.xml in playstore folder contains only informations specific to the play store apk: eg. reference to the WearableServices class, keys for playstore services
- AndroidManifest.xml in genericstore folder contains information for non-playstore apk: mainly, empty

See the differences in the following image:

Differences between Manifest

After this operation I created two product flavors in the gradle file of my app like this:

android {
     compileSdkVersion 20
     buildToolsVersion '20.0.0'
     productFlavors {
          playstore{
               applicationId "com.andrea.degaetano.coffelover.playstore"
          }
          genericstore{
               applicationId "com.andrea.degaetano.coffelover.genericstore"
          }
     }
… … (other unchanged configurations here..)
}

The new build.gradle file generated 4 new “Build Variants” in Android Studio.
This new menu allows the developer to select which kind of build generate:

All my modules.. and the selected variant
you can change the selected variant on any module

At this point, if you try to export the apks, the genericstore apk fails, because the android wear apk is present in the genericstore apk and the package of the genericstore is different from the one in the android wear apk.
Not only, but the genericstore apk is always 3.9mb.

In order to remove the dependency from android wear in the generic apk, I have changed the dependencies of my application from:

dependencies {
     compile project(':parseLoginUI')
     compile 'com.android.support:support-v4:20.0.0'
     compile 'com.google.android.gms:play-services-wearable:7.5.0'
     compile 'com.android.support:appcompat-v7:20.0.0'
     compile files('libs/android-async-http-1.4.6.jar')
     WearApp project(':qoffeewear')
}

to

dependencies {
     compile project(':parseLoginUI')
     compile 'com.android.support:support-v4:20.0.0'
     playstoreCompile 'com.google.android.gms:play-services-wearable:7.5.0'
     compile 'com.android.support:appcompat-v7:20.0.0'
     compile files('libs/android-async-http-1.4.6.jar')
     playstoreWearApp project(':qoffeewear')
}

Important: The package of the android wear app is the same of the playstore variant: com.andrea.degaetano.coffelover.playstore

Thursday, 28 May 2015