Wednesday, December 23, 2015

Well, I just received a couple of these nifty devices from Amazon.

Being in Canada, it's basically useless right now but I have a lot of ideas on what we can do with these medicine tablet size devices.

The Dash has a basic ARM processor and WIFI connectivity, and once you set it up on your mobile device thru the Amazon app, depending on what product you set it up to buy from Amazon, every time you push the button it will connect to your WIFI router, submit the command thru Amazon (log a purchase) and then turns itself off to save power.
Now, if you didn't set up a product for purchase in your Amazon App, it will basically just connect to your WIFI router, and then disconnect.
With this behavior, we can create a monitoring app (ARP Probe), which just detects if Amazon Dash  connects to the WIFI router, and then based on this, trigger an action.
Here are some of possible applications the Dash can be used for with IFTTT:
1. Doorbell  - Push the button, trigger a notification on all the iPads, android machines
2. Door Opener - Push a button, opens a zwave door lock
3. Picture taker - Push a button, grabs a snapshot from my webcam running on the dockstar and email it
4. Light switch - Push button, turn on a zwave light (no need to grab phone, open app, turn on)
5. Garage door opener - Open the garage from living room (might be a security risk)
6. Data logger - Push a button everytime you drink medicine, post it to a spreadsheet so you'll track it.
7. Self Destruct - For the paranoid people out there, a self destruct switch, which turns on wemo/zwave switch that turns on an electromagnet besides your hard drive.
8. etc.
The common denominator would be is that you'd need an always on machine, like a Raspberry Pi, Dockstar, Openwrt router, Smartthings, file server PC, etc.  that is running Linux or Windows and when the button is pressed, a monitoring program will detect the MAC address of the Dash, depending on what triggers you have setup in IFTTT (example: file created in Dropbox, send an email to IFTTT, etc.) and when IFTTT detects that, it will then generate a subsequent action like turn on the light (via Wemo, Smarthings, Hue), Post a facebook/instagram/twitter message, and lots of other actions.
Stay tune for number 3, I'm planning on having the Amazon Dash post a screen cap from my dockstar's mjpg-streamer automatically to either my FB acct or instagram whenever I push the button.

Thursday, February 26, 2015

My 22TB RAID file server

Sans Digital 8 Bay eSATA Enclosure

My GoFlex Net 22TB NAS

I've been meaning to write up my experiences in creating my cheap 24TB GoFlex Net setup, but I haven't found the time until now.

Now, I've been buying 3TB drives when they were on sale for years now, whenever it goes below $100, I bought one each time, and was planning on just plugging it in my Pogoplug or a desktop HTPC so I can have my file collections accessible online.

Eventually, I was able to buy an 8-bay eSATA enclosure from for around $160 which was quite cheap compared to the regular price of over $300... It had two eSATA connectors, and the card that came with it supports RAID setups, which I opted not to use.

I have 4 3TB drives and 4 2TB drives installed  in it, totaling 18TB and was using my HTPC as the network server for my iPads, Androids, XBMC, WDTV, XIOS, etc. and it was ok for a while...

However, having a 300W PC server, is a bit excessive as all I really needed was a fileserver, and I looked for a more energy efficient option.I shopped around for any 4 or 8-bay NAS and was surprised it costs more than what a PC is worth and appalled that an 8-bay NAS with no Disk costs more than a thousand dollars, and probably powered by a so-so processor that even the slowest Celeron PC can run around circles with.

I looked at Cubieboards (1 SATA port), Raspberry Pis (USB only), Beaglebone Blacks (USB) and even Cubox-i4Pro (1 eSATA port) and only the Cubox-i4Pro would probably be able to handle the 8 drives, but it would involve splitting the single eSATA port to two SATA connectors, which would in-turn split into 4 drives each, and I'm wary that a single SATA bus would be able to handle it.

Then I found out about the Seagate GoFlex Net, 
Seagate GoFlex Net

which was an fork of the Pogoplug, it supports two SATA drives, and more importantly those SATA bus supports Port Multiplier, allowing me to use my 8-bay enclosure.

The GoFlex Net is now discontinued, as the Pogoplug Cloud didn't really take off, but it is hackable to install Linux on it. My first try was to use Arch Linux, but Debian has a number of fairly good packages I switched to Debian instead and installed Open Media Vault.

I will be discussing later on how I was able to install Debian on the GoFlex Net and the uBoot settings I had to configure for it to be able to boot from the first drive (freeing up the lone USB port) and how I soldered an external power connector (which I took from an old internal fan connector) so I can power the GoFlexnet from the enclosure power supply.

But just to show you it is doable, here's a couple of pictures of the GoFlex Net mounted inside the 8-bay enclosure, thereby giving me a cheap 8-bay NAS. I've accumulated more than 8 3TB drives, so I was planning on installing all of them to have 24TB, but I had problems booting on the 3TB drive due to the Linux's limitation. I was able to boot off a 3TB on my Seagate GoFlex Home (which is a 1 SATA Pogoplug clone), but I was having a hard time to do in on the GoFlexNet, so I opted to just use a 2TB drive for my first two drives in the enclosure... I was planning on setting up RAID on the first two drives and then another RAID for the rest of the 3TB drives, but in the end I just set them all up as independent drives (Disk 1 to 8) and just use RSYNC to back up the important files (which are just pictures, home movies, etc)... Hence I have 22TB  of storage accessible...

GoFlex Net inside the eSATA enclosure

Plugged the SATA cables directly to the GoFlex Net

Tuesday, February 26, 2013

Installing Debian "Wheezy" for Pogoplug/Dockstar

Just some notes on how to install Debian "Wheezy" on the Pogoplug/Dockstar:

If you google on how to install Debian on the Pogoplug/Dockstar/Seagate Goflex Home/NET, you will ultimately wind up to the url:

However, the script is designed for newer kernels, and may not work (the script will fail and  the logs will tell you that your "kernel is too old").

There are two ways of going about circumventing this problem:

1. Install Debian "Squeeze" and update to Wheezy:
    Find your devices's IP address and connect via SSH:
username: root password: (the password is 'stxadmin' on Seagate branded devices and 'ceadmin' on Pogoplug devices)
Partition your flash drive with fdisk:
fdisk /dev/sda # Configure partion 1 as Linux (I'd recommend making this at least 512Mb. The default bare-bones installation uses 280Mb.) # Configure partion 2 as Linux Swap (I used 256MB. Adjust according to your anticipated memory usage.) # Set partition 1 active
Download and run the Debian Squeeze installer:
cd /tmp wget chmod +x export PATH=$PATH:/usr/sbin:/sbin ./

Update to Wheezy:

apt-get update apt-get dist-upgrade reboot
And Voila! You're running Debian Wheezy!

2. Install Arch Linux or some other Linux derivative, boot from that, login and:
Install Rescue system (this replaces the Pogoplug partition with a powerful rescue system.
cd /tmp wget chmod +x ./
We also need to disable perl so the the debian-wheezy script does not bomb out. (after installing rescue)
mount -o remount,rw / chmod 666 /usr/bin/microperl rm /usr/sbin/debootstrap rm -rf /usr/share/debootstrap mount -o remount,ro /
then install Debian Wheezy as per original instructions.
cd /tmp wget chmod +x export PATH-$PATH:/usr/sbin:/sbin ./

This  way is only recommended when you are already running a Linux distro other than the firmware pogoplug distribution. In my case, I have my dockstar running on ArchLinux, but I wanted to try the new Debian Wheezy on it. At first try, it bombed out complaining of "kernel too old" from the log files. But when I   installed the Rescue Partition and installed wheezy again, it worked!

Sunday, December 23, 2012

Pogoplug Security Camera

Pogoplug Security Monitoring System

Continuing on from our Raspberry Pi set-up of a streaming internet webcam, I have modified my setup to use a Pogoplug (or Dockstar, which is basically the same hardware) as my security camera system. The Pogoplug V2 Grey has a 1.2Ghz Marvel Kirkwood ARM9 processor while the Raspberry Pi has a 700Mhz Broadcom BCM2835 ARM176 core with hardware floating point. Basically the processing power of the Pogoplug is much more than the Raspberry Pi although graphically the Pi is much more capable with it's GPU.

But since my main purpose is to make a headless webcam security system (not plugged in to a TV or monitor), the Pogoplug is more suited for this application.

Here's a sample of the final output of my webpage:

The top header is just a bunch of scripts I used to show the current temp, visitor info, current Winnipeg time and the time in Asia.

The webcam views are from local ports, but if you want this to be viewable from the internet, you would have to define routing tables using your router to route traffic from the internet port to a particular web stream.

In this case, if your pogoplug has an IP address of and the webcam stream are from port 80 and 8080 (for each webcam), then you would have to define an incoming port (from the net, example port 88) and route it to local port of If you have a DD-WRT router, you basically would have to just go to your router's IP (in my case and pick the NAT/QoS tab, and setup Port From 88 to route to and port 80...  This would mean, any reference to http://<youripaddress>:88 would automatically route to the pogoplug's port 80.

If your Internet service provider randomly assigns an IP address each time you connect to the net, you would need to know your new Internet IP address, but if you use a DNS redirector, you would just need to remember your website. 
In this example, I am using a free DNS redirector from DYNDNS to use the site <myfreesite> and it is updated daily with my router's internet address. You can replace this with whatever web address you already have or subscribe to a free DNS redirector like DYNDNS. You can then automate your update to Dyndns by logging in to their site with your username/password and it will record your IP address as the address to go to whenever you logon.

DD-WRT has a DDNS tab that will automatically logon and update the DYNDNS table to your current IP.


Host name is your dynamic DNS website name, example:

Here's a sample code form webpage:


<title>Roland's webcams</title>
<meta http-equiv=refresh content="3600"></head><body>

<table border="0"><tr>
<a href=>
<img src= height=260 width=360></a>
<a href=>
<img src= height=260 width=360></$

<a href=>
<img src= height=260 width=360></$

The first webcam grabs the output of my old NSLU2 (the predecessor of the Pogoplug) which is basically a NAS device that I reverted to a webcam server, while the latter two are hosted in my Pogoplug and runs two instances (actually 4, the other two are webcam image captures stored as JPGs) of MJPG-Streamer. 2 web services that serves the video stream (for each webcam) and 2 file streams that saves an image per second for the 2 webcams. The NSLU2 is not powerful enough to do image conversion (JPG to AVI) so I haven't been saving the stream.

The Pogoplug setup generates a webstream for each webcam (accessible from the internet from any device) and also a   jpeg of the image per second into a defined directory (cam1 and cam2). Every 2 hours, it shuts down the mjpg-streamer (using "pkill mjpg-streamer"), renames the cam directories  to (X for the webcam number) and restarts the webcams/file streamer. Once it restarts the capture, it will then convert the renamed directory's JPG files to an AVI and when done, it zips the JPG into a file under the processed directory (deleting the jpgs in the process). After the zip process, it will delete the now empty directory.

The JPG to AVI conversion is handled by ffmpeg and usually takes 40 minutes per camera. Zipping the files into a zip file takes around 5 minutes, so the basic processing time for both cameras is approximately 90 minutes. During those 90 minutes, any additional processing may push the processing time to conflict with the scheduled re-run of (i.e. a second instance of may run when the 90 minute process gets pushed beyond the 120 minute cron process). Since I made the pogoplug into a SAMBA server (use pacman to install SAMBA), I am able to go into the Pogoplug's drive from a Windows/Mac PC and copy the files (or watch the stored AVI) to my local machine. This eats up processing power from the Pogoplug, and if there was a huge file transfer process, may not have enough time to do all it's work within 120 minutes.

The default conversion is to an AVI file. Using better compression (MP4 format), it will take the Pogoplug more than an hour, so I opted to just zip the JPGs and convert those from a different PC as needed.

Basically my setup consists of:

1. Pogoplug Grey V2 (same as the more common Pogoplug Pink V2)
2. USB external portable 500GB hard drive
3. 2 pcs of Logitech Quickcam 9000 Pro webcams
4. Dlink Powerline Network adapter (or use a USB WIFI adapter/network port) - I'm using this because the location is a hard to reach.

The Pogoplug is running Arch Linux (the same version I installed in my Raspberry Pi), and I added the packages of mjpg-streamer, ffmpeg, and zip/unzip. (to install a Arch Linux Package, use pacman)

A great step-by-step instruction on how to install Arch Linux in a Pogoplug can be found here:

After converting the Pogoplug to Arch Linux, just follow the same steps as with my previous posts on the Raspberry Pi Webcam server, but with modifications on the

pkill mjpg_streamer
STRNAME1=cam1-$(date +%Y.%m.%d.%H%M)
STRNAME2=cam2-$(date +%Y.%m.%d.%H%M)
mv /media/share/cam1 $STRPATH1
mv /media/share/cam2 $STRPATH2
mkdir /media/share/cam1
mkdir /media/share/cam2
/usr/bin/mjpg_streamer  -i " -d /dev/video0 -f 10 -r 960x720"\
  -o " -p 80 -w /media/share/www"\
  -o " -f /media/share/cam1 -d 1000"\
/usr/bin/mjpg_streamer  -i " -d /dev/video1 -f 10 -r 960x720"\
  -o " -p 8080 -w /media/share/www"\
  -o " -f /media/share/cam2 -d 1000"\
for file in $STRPATH1/*.jpg; do
    printf -vsequenceImage $STRPATH1/%05d.jpg "$((++i))"
    [[ -e $sequenceImage ]] || \
        mv "$file" "$sequenceImage"
for file in $STRPATH2/*.jpg; do
    printf -vsequenceImage $STRPATH2/%05d.jpg "$((++i))"
    [[ -e $sequenceImage ]] || \
        mv "$file" "$sequenceImage"

ffmpeg -f image2 -i $STRPATH1/%05d.jpg /media/share/processed/$STRNAME1.avi

ffmpeg -f image2 -i $STRPATH2/%05d.jpg /media/share/processed/$STRNAME2.avi
zip -m /media/share/processed/$ $STRPATH1/*.jpg
rmdir $STRPATH1
zip -m /media/share/processed/$ $STRPATH2/*.jpg
rmdir $STRPATH2

The basic process is, at first run, kill all instances of MJPG-STREAMER, rename the cam1 and cam2 directory to a unique folder name, and then create a blank cam1 and cam2 directory. Launch MJPG-Streamer and store a picture every second. This process runs very quick so at most we only lose 1 second of video in the switch process. After that, the old cam1 directory is processed to rename all the files into a sequential file name convention, and the same is done for the cam2 directory.

The process takes a bit (approximately 5 minutes) and my old python script does this around 5 seconds, so I have yet to refine this step to make it run within the bash script.

The next step is to generate the AVI files from the JPG images, and this process takes around 40 minutes (each directory) and will probably eat around 70% CPU. However, this still leaves a bit more CPU muscle for basic stuffs like file copy, mpeg streaming and web services.

After the AVI generation process, the JPG files are zipped to a ZIP files and moved to the PROCESSED directory. The blank cam1 directory is then removed for a cleaner directory structure.

EDIT 6Mar2017: Here's my new script, using mencoder

pkill mjpg_streamer
STRNAME1=pogoplug-$(date +%Y.%m.%d.%H%M)
STRDIR=/media/hdd/share/processed/$(date +%Y.%m)
if [ ! -d "$STRDIR" ]; then
   mkdir $STRDIR
mv /media/hdd/share/cam1 $STRPATH1
mkdir /media/hdd/share/cam1
/usr/local/bin/mjpg_streamer -i "/usr/local/lib/ -d /dev/video0 -f 10 -r 1600x896"\
  -o "/usr/local/lib/ -p 80 -w /media/hdd/share"\
  -o "/usr/local/lib/ -f /media/hdd/share/cam1 -d 1000"\
if [ -f STRNAME1.txt ]
  rm STRNAME1.txt
ls $STRPATH1/*.jpg > STRNAME1.txt
mencoder -nosound -mf fps=15 -o "$STRDIR/$STRNAME1.avi" -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=8000 mf://@STRNAME1.txt
rm -r $STRPATH1

I've modified my original script to make it more faster and removed the secondary step of looping in files to rename it to a sequential number.. Since the files are sorted by date (ascending), I just generate the a text file with the names of the pictures, pass it to mencoder, which will generate the AVI file. The file name generated will have the current date and time so that I will know the sequence. I've removed the ZIP process as I do not need the old files, but you can put it back if you want (just copy the previous script)...