Thursday, 4 December 2014

Wireless Garden sensing Prototype A and B (Intel Galileo, Spark Core and Grove)

We have a small garden at home and adding sensors to it was merely a matter of time, specially now that winter is coming, and it is time to plant our pepper and tomatoes plants.  Below are the two iterations made to my wireless gardening sensor (still in beta stage).

Prototype A: Intel Galileo on board

For the first prototype I used the Intel Galileo Board I won at Senzations, the objective was to test the sensors, familiarize with the obtained values, and test publishing to Ubidots.  For the test I used my wife's pepper plant.

Light, Temperature and Humidity are variables easy to understand and correlate, but as there was litle information about the Soil Moisture sensor itself, I measured both with the sensor in the free air and submerged into a glass of water, I found out the range was between 0-700 units.  The next step was to water the pepper pot and see the Soil Moisture value when the plant if fully watered, then see the chart going down until the next watering session (when the leaves are "sad" as my wife says), so we can see at which values do we have to trigger an alert.

The actual code was mostly taken from Ubidots examples, as the sensors at this present stage are mostlly analogue, it was only required to use the analogRead() call from the Arduino API.  The sensors are from Grove: the temperature and humidity sensor is I2C-based, the soil moisture and light sensor are analogue.

 Prototype B: Spark Core

With the sensors and the Ubidots platform figured out, the next step was to make the whole thing to run on battery as a stand-alone device.  For this I used the Spark Core I won at IoTogether Hackaton along with a battery charger board I steal borrowed from work, and a 3.7V 800mAh Li-ion battery connected to a battery charging circuit.

To avoid having to solder a wire to the USB 5VDC pin I added a scrambled jumper logic to enable charging the battery when connected to the micro-USB, else the Spark Core will be powered by the battery only.  I have also one power input to throw in a solar panel and charge the battery in the day and discharge over the night, but I still have to figure out how to adapt it to the enclosure.

I added 2 Phidget-like connector to be able to connect Phidget sensors or analog ones following the same pin-out (VDC/GND/Signal), and one Ziglet-like connector to connect any I2C-based sensor, as at the end I want to use digital sensors to keep the power consumption as low as possible, having wired a GPIO pin also to the connector to use interrupts from the sensors as well.

The male pin-header exposes unused GPIOs to be used later, for example one wandering idea is to add an MP3 board with an amplifier and a small speaker, as allegedly this helps plants grow, or maybe do a playback of my wife talking to the plants, which one was it? nevertheless it would also be kinda cool to play nature music when presence is detected... this will be likely an improvement to make if the power consumption can be kept low.

One caveat: I was one of the unlucky Spark owners who had a board with faulty DNS resolve, so I had to include an external DNS client to resolve Ubidots IP address, and then add the host property to my header and initiliaze the Server IP address as shown below:
http_header_t headers[] = {
     { "Content-Type", "application/json" },
     { "X-Auth-Token" , TOKEN },
     { "host", "" },
     { NULL, NULL }

IPAddress dnsServerIP(8,8,8,8);
IPAddress remote_addr;
DNSClient dns;

char serverName[] = "";

void setup() {
    request.port = 80;    
    dns.getHostByName(serverName, remote_addr);
    request.ip = remote_addr;

Then to take advantage of the Spark low power mode and try to save battery as most as possible, I use the SLEEP_DEEP_MODE to put the Spark to sleep and awake after 5 minutes, rebooting the code with no memory retention, which is fine in my case as I only want to take single readings and upstream these.  The code runs as follows:

void loop() {
    // Read data from the sensors
    // Send data to Ubidots
    // Short blink to indicate we have finished posted

    // Stay awake enough time to allow being reprogramed        
    // Put the core back to sleep

The AWAKE_BEFORE_SLEEP delay makes sure the Spark Core stays awake for 20 seconds, which gives me enough time to reprogram the Spark over the Web IDE from my PC without having to connect the Spark to the host over USB.  One of the things on my to-do list is to measure the current consumption of the device.

The whole thing fits into a standard enclosure, one of the things I have still pending to do is to adapt the sensors to the enclosure, make a small window to be able to visualize the LED, and also fix the solar panel.  I have convinced my daughters to paint the enclosure with a festive theme, so surely I will post this anytime soon.

So that's it, I'm hoping in the holidays to have time to improve the Prototype B, make some measurements and work on the solar panel.  One of the things I will surely test is the ESP8266 cheap WiFI board, but with my Photon already ordered in pre-sale for next year, I think it will make worth the wait, in time for the Prototype C, maybe even a release.

Bring Oneiric-based distros back to live in Linaro and IGEP board

Following the end-of-year tradition of updating production boards, I found an ISEE IGEP v2 board running Linaro distribution on an Oneiric-based release, which reached end of life on May 2013.  One option would be upgrading to a new LTS distro, but as time was limited and the current owner has a if-works-don't-touch strict policy, I choosed instead to update at least its sources:

W: Failed to fetch 404 Not Found

Just edit the /etc/apt/sources.list file and replace with the following:

deb oneiric main
deb-src oneiric main
deb oneiric-updates main
deb-src oneiric-updates main
deb oneiric universe
deb-src oneiric universe
deb oneiric-updates universe
deb-src oneiric-updates universe
deb oneiric-security main
deb-src oneiric-security main
deb oneiric-security universe
deb-src oneiric-security universe

Then run:

sudo apt-get update

Don't forget to also test for ShellShock vulnerability.

Wednesday, 3 December 2014

Fix Shellshock on non LTS/deprecated Unix distros

Plenty of things have been said about Shellshock vulnerability and solutions, most of them consisting of upgrading the bash module for LTS distros, but lately as I have dusted my ALIX board based on Voyage 0.9.0 distribution, I found this was not an option: even after upgrading and downloading the bash packet from the dist pool, there were requirements missing to upgrade/install bash from the packet manager. This was my current bash version:

# bash --version
GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>

The bash version did not matched the fixed ones, anyways to test if you are affected you can run on a terminal the code below, if both lines are showed, then it is affected.

# env X="() { :;} ; echo busted" `which bash` -c "echo completed"

I found a fix at ShellShocker and it was as easy as running the snippet below (although I would not recommend executing remote scripts, it is not a good practice), but if you are curious about what it does, or you want to run this yourself, the sources are also listed below.

curl | sh

After running the script the bash has been patched and the shellshock test now ommits the "busted" line.

# bash --version
GNU bash, version 4.3.30(1)-release (i586-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>


Fix EXT2 ext2_lookup deleted inode referenced

Deleted inodes are a common problem when working with SD cards, specially noticeable in ALIX-bsaed boards running Voyage or alike.  Remove the SD, connect as an external drive to your host (I'm connecting to an Ubuntu-based VM) and do the following:

$ sudo fdisk -l

Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders, total 31457280 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000cb32b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048    28350463    14174208   83  Linux
/dev/sda3        28352512    31457279     1552384   82  Linux swap / Solaris

Disk /dev/sdb: 3997 MB, 3997163520 bytes
128 heads, 63 sectors/track, 968 cylinders, total 7806960 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfc8a205c

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1     7370495     3685247+  83  Linux

Identify your disk using the information above, then check and repair the file system using e2fsck, when prompted you can comply with the suggested fix by pressing "y".  This should be the output if no errors are found.

$ sudo e2fsck -f /dev/sdb1 
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
ROOT_FS: 121871/230608 files (2.0% non-contiguous), 807088/921311 blocks

Tuesday, 2 December 2014

Disable 6lbr to be launched at boot

I luckily found out 6lbr some months ago (I have an unfinished post about it yet to finish, loving foren6 also), but I needed to stop the service to be launched from boot while I did some testing.  As I didn't found any configuration tweak to do so, I disabled the service at all /etc/rcX.d run levels using the well known update-rc.d script.

update-rc.d -f 6lbr remove

To enable back:

update-rc.d 6lbr defaults

And business as usual.

Monday, 1 December 2014

Stop the LG SmartShare service to be launched at boot (Windows 7)

Short story: LG SmartShare DLNA media sharing service was slowing down Windows boot abnormally, and the built-in settings do not provide the polite option to disable launching the application at boot.  After checking the usual suspects (msconfig and Startup folder), I found where the SmartShare task was being scheduled.

Just go to the Administrative Tools menu and open the Task Scheduler.