My headless Raspberry Pi server [day 5 of 20-days-of-posts series]

Intention: To be used as a headless download server -- nzbget, transmission, http stream download, gdrive upload/download, etc.


Equipment:

• Raspberry Pi (model B -- memory: 512MB, 2 USB port, ethernet)
• class 10 SD card (32GB)
• micro USB connected to high- powered USB 2.0 hub (new - integrated)
• 2amps, Pi-friendly (Monoprice 7-port USB hub)
• integrated multi-coloured LED (new) (see USB WebMail Notifier)
• power switch with reset button (rocker-style)  (new) (see Adding a power switch to the Pi)

Assumptions:

• No need for the VIDEO port (going to use HDMI)
• No need for AUDIO jack (going to use HDMI)
• Minimal need for HDMI; only for troubleshooting boot issues
• No need to access camera port, GPIO pins, etc
• Continued use of a 1.8/2.5" SATA drive for primary storage

The headless server will be connected directly to the router via ethernet (no need for wifi).  There is no need for a keyboard or mouse.  One USB port will be occupied with a connect to the hub.  The 2.5" SATA hard drive will be plugged into the powered USB hub.  The second USB port would be used for a keyboard when needed for troubleshooting.


Like with most of my lego projects, I don't provide full schematics and block lists.  My opinion is that if you have unused lego that you can use for a project like this, you make use of what you have, improvising as you go.

This is my "spruced" up Raspberry Pi, where I have integrated a rocker-style power switch (with reset butt) and integrated 7-port USB hub (Monoprice 7-port USB hub).  The hub is powered by a 2amp power brick.  The power brick is fairly slim -- in a power bar, it would prevent another brick being plugged into the plugs next to it, but it does provide enough clearing to allow someone to plug a power cable into adjacent plugs.  The hub will provide enough power (1amp) to power the Pi.  Unlike other high-powered USB hubs that I have tried, the hub will provide greater than 0.5amp to device connected to it even though there is no host connected to it.  This is critical.  A lot of other hubs I have tried, they will provide high-power to a USB device connected to the hub only if there is an established host connection to the hub.  Therefore, if you try to connect a Pi to the hub, it is not able to provide enough power to the Pi to start it up because there is no host connected to the hub.  The Pi needs to be powered up before it will establish a host connection with the hub.

With the Monoprice 7-port USB hub, the hub will provide enough power the usb connections to power the Pi up even before the host connection is established.  This is witnessed by a red light on the hub, which indicates it is powered on.  When the Pi itself is powered on and started, blue lights will turn on the hub to indicate connections of those devices to the host have been established.

The hub also prevents backpowering over USB if there is a USB cable connected to the micro USB power port on the Pi using any one of the powered USB ports on the hub.  This allow for a switch to actually work.  Without this ability, the power switch would be futile as the Pi would become powered on automatically via the host connection between the Pi and hub when the hub gets powered on.

The hub will provide 3 internal USB connections (used for things embedded into the lego case), 2 top USB connections and 2 USB connections along the same side as the Pi's USB ports.

First actions that were performed was the readying of the USB webmail notifier, (disassembling, cutting and resoldering the wires) described in a previous post.

Second actions that were performed was the readying of the USB hub.  The plastic case was removed, which was fairly simple enough.

Power Consumption:

Measured with a kill-a-watt meter, here are the power consumption numbers for this Raspberry Pi server.

	Consumption (Watts)
USB Hub (idle)	~ 0 W
Raspberry Pi w/ rocker power switch w/ USB Hub	2.5 W
Raspberry Pi w/ rocker power switch w/ USB Hub w/ 2.5" 5400rpm Hard Drive	5.5 W (idle) 6 - 6.5 W (spin up)

Front-side view: 

Before:

After:

Like the original server-pi case I constructed previously, I have a 2.5" HD drive bay for which I provide ventilation lego bricks.  You can see where the deconstructed hub sits, right on to of the Pi.  The left inset window shows the lights from the hub (red and blue).  The right window where I have situated one of the deconstructed USB WebMail Notifier LED lights.  It is plugged directly into a USB port on the hub (one of three that are "internal", obstructed by the lego case).

Not much to see from the front side view; no special windows or openings.  The ventilation holes are for 2.5" SATA hard drive.  The bottom extends out 1 lego brick outward to accommodate the 2.5" hard drive being wider than the size of the Raspberry Pi.

The video and audio ports are intentionally inaccessible.  The Raspberry Pi LEDs are also covered.

The height of the original case was 5 blocks.  The revised case uses 7 blocks.  The length of the case is 16 blocks, which is actually down by 2 blocks (originally was 18 blocks), even considering that we added a power switch that is 3 blocks in length.

Right-side view:

Before:

After:

The SD card slot is now accessible.  The SD card depicted has a plastic "extension tab" tapped to it so that I can slide it in and out.  I needed to accommodate the power switch on this side, and that prevented me from dropping the length of the front side by another block size, that would have provided me enough access to the SD card without an "extension tab".  The micro USB power connect of the Pi is now opened up (as opposed to the old setup of internally wiring the port to the opposite side).  I've added a "flag" swing door.  There are these two pole holders on the case (one is depicted with a black lego pole).  I use have these attached so I can slide out these poles and use them to hit the internal reset button on the power switch (more on that later).

A top side perspective of the same-side:

Back-side view:

Before:

After:

You can see the minimum width of the case has been extended by 1 block size, and around the HDMI port, the unit's width gradually extends further out two block sizes.  This is to accommodate the hub that sits overtop the pi.  There is a slight opening of 1/3rd block size along the base of the daughter board board on the hub.  Two of the upright facing ports are attached to the hub by a daughter board.  Instead of making the unit an additional block size in width, I leave this gap to accommodate this board.

The blue window swings open from the top and provides access to the HDMI port.  I only use this when troubleshooting boot-up issues.

Left-side view:

Before:

After:

There are a lot of changes on this side.  We have access to the ethernet port and the two USB ports.  The Raspberry Pi LEDs are no longer covered up, viewable through a window.

I have added a flag door, similar to the opposite side, where it can be swung up or down, to cover up partially or completely, the two USB ports on the Pi.

With the integrated hub, we now have two USB ports accessible that are powered by the hub.  The entire unit (with Pi) are powered by the dim socket, connected to a 2amp 5V power brick supplied by the hub.  The right micro USB port on the hub is the host connection port.  It will be wired to one of the Pi USB ports by a short micro USB cable, depicted later on.

The 1.8" or 2.5" SATA hard drive slides in the bottom base.   The door panel mechanism that I used to snap on before has been replaced (since I found they often fell off).  Instead, I have another one of those flag pole mechanisms, where I slide it vertically up or down.  When in the down position, it will obstruct the drive bay opening, preventing a hard drive from sliding out.


Top-side view:

Before:

After:

From the top view, we can see have access to two upper powered USB ports.  These are handy for plugging in flash drives, external hard drives, etc.  One I typically will use to power the Pi using the power switch.  You could also just backpower the Pi using the host connection alone, but then you won't be able to power the device on/off with the rocker-style switch, nor reset it using the reset button.

The rocker-style power switch is accessible by the swinging upper door.  The reset button (next to the switch) can be toggled by using the flag pole.

And the bottom....

From the bottom-side view, we can see the base the size is 16 by 12 blocks.

Wired up...

Now time for some action shots.

The first video demonstrates booting up and turning off.

With the test.sh script running on the integrated multi-coloured LED.

USB WebMail Notifier [day 4 of 20-days-of-posts series]

I picked a few of these USB WebMail Notifiers from TheSource (made by Dream Cheeky).  They are common, places like DX carry a multitude of them cheaply.  The local store had them on clearance for less than a dollar.

The model number is 8003037.

The raw USB device information is:

DEVTYPE=usb_interface

DRIVER=usbled

PRODUCT=1d34/4/2

TYPE=0/0/0

INTERFACE=3/0/0

MODALIAS=usb:v1D34p0004d0002dc00dsc00dp00ic03isc00ip00in00

The instructions for the device: http://www.thesource.ca/sitelets/gadgetree/downloads/8003037_om_en.pdf

It comes with a mini-CD for installing drivers for Windows XP.

The designed use of the device is to flash different colours based on various email incoming alerts.

It's a basic USB device.  There are several cross-platform projects, most implemented in Python, since USB device driver support is extensive in Python.  One such project is https://github.com/konker/dreamcheeky_notifier

If you are using Linux, you can control the device using the /sys/devices/..

If you do a search for a handler call "green" such as find /sys | grep green, you should find where the device is located.

On my system I get /sys/devices/pci0000:00/0000:00:1a.1/usb2/2-1/2-1:1.0/green.  For the device, there should be inputs blue, red and green.  Each input represents the lighted value for that colour.  The value accepts input values from 0-255.  In actuality, each colour has effective values from 0-100, 0 representing off and 100 representing maximum light intensity.

Either through a Python script using the PyUSB device driver, a developer's open-source offering or by controlling the colours manually with the device driver, you can use the device for an infinite number of applications.  You can essentially use the device as a multi-coloured LED that you can turn off or flash different sequences or colours based on a set condition.  The controlled intensity makes the LED very visible.

You can control the device by echoing the value 0-100 into a combination of blue, red and green.  You'll need to first give your user ability to write to the device (sudo chmod 666 blue; sudo chmod 666 red; sudo chmod 666 green).  Then a simple echo 50 > blue would set the device to exhibit the blue colour on the LED with half intensity.

Here are two videos displaying the sequence demonstrated in the script below:

script: test.sh

Here is a video demonstrating the transitions from 0 to 100:

script: transition.sh

When you take the device apart, you see it's essentially a multi-coloured LED attached to a simple logic board.

For my application, I further cut the cable near the USB plug and near the logic board.  I then used a pair of scissors (carefully!) to splice away the shielding cable from the connector.  I then shaved away the shielding cable from the cut ends, spliced off the 4 wires, and soldered the two ends back together.  Heat seal tape over the solder joints (to avoid wires of different types from contacting eachother) and then heat seal tape over the bundle so that I'm left with a logic board connected to the USB connector by a short set of wires.  I then slid this into one of my raspberry pi lego cases, providing a multi-coloured LED that I can use to view various conditions on the pi (this pi runs as a headless server pi, so there is no screen attached, making it difficult at times to quickly check on things).  I use the LED programmed in a bunch of different scripts to visually display statuses to me, so I can visually see the status by looking at the unit.

A simple system LED as easy as pi ;)

My original Raspberry Pi server lego case [day 3 of 20-days-of-posts series]

Intention: To be used as a headless download server -- nzbget, transmission, http stream download, gdrive upload/download, etc.


Equipment:

• Raspberry Pi (model B -- memory: 512MB, 2 USB port, ethernet)
• class 10 SD card (32GB)
• micro USB connected to powered USB hub

Assumptions:

• No need for the VIDEO port (going to use HDMI)
• No need for AUDIO jack (going to use HDMI)
• Minimal need for HDMI; only for troubleshooting boot issues
• No need to access camera port, GPIO pins, etc
• Continued use of a 2.5" SATA drive for primary storage

The headless server will be connected directly to the router via ethernet (no need for wifi).  There is no need for a keyboard or mouse.  One USB port will be occupied with a connect to the hub.  The 2.5" SATA hard drive will be plugged into the powered USB hub.  The second USB port would be used for a keyboard when needed for troubleshooting.


Like with most of my lego projects, I don't provide full schematics and block lists.  My opinion is that if you have unused lego that you can use for a project like this, you make use of what you have, improvising as you go.

Front-side view: 

Not much to see from the front side view; no special windows or openings.  The ventilation holes are for 2.5" SATA hard drive.  The bottom extends out 1 lego brick outward to accommodate the 2.5" hard drive being wider than the size of the Raspberry Pi.

The video and audio ports are intentionally inaccessible.  The Raspberry Pi LEDs are also covered.

Right-side view:

I'll user a better camera next time :)  Again, the bulge is to accommodate the hard drive.  You can see that the total height of the unit is 5 lego blocks.

The micro USB power port and SD slot are intentionally covered / inaccessible.

Back-side view:

Not much to see from the back side view.  The blue window swings open from the top and provides access to the HDMI port.  I only use this when troubleshooting boot-up issues.

 The ventilation holes are for 2.5" SATA hard drive.  The bottom extends out 1 lego brick outward to accommodate the 2.5" hard drive being wider than the size of the Raspberry Pi.

Left-side view:

Much more to see from this end.  We have access to the ethernet port and the two USB ports.  The raspberry pi LEDs are covered up, which will be addressed in a future revision.  The power micro USB cable is routed internally from the port accessible on the "left-side view" and breaks out on this side.  The cable will be plugged into a powered USB hub.  The 2.5" SATA hard drive slides in the bottom base, and two removal pannel doors connect to the right and left sides to keep the drive in place while providing access to the USB port on the drive and the drive's access LED.


Top-side view:

The top view gives a clear indication on the size of the unit.  At the base it is 18 by 12 blocks, with a loss of 1 block size in width past the hard drive bay.

There are two accessible swing doors.

Inside, the micro USB power cable is accessible, and the SD card can be accessed.


There is a lot of room for improvement in this case design and the transformation will be remarkable....

ThinkPad keyboard overlay for non-ThinkPads [day 2 of 20-days-of-posts series]

Yesterday I discussed a workaround in Linux to remap keyboard keys to mouse buttons to cope with a trackpad (http://ddurdle.blogspot.ca/2013/12/living-with-laptop-without-trackpoint.html).  Today I demonstrate a ThinkPad keyboard overlay that I created for my Ultrabook.

Like with most of my lego projects, I don't provide full schematics and block lists.  My opinion is that if you have unused lego that you can use for a project like this, you make use of what you have, improvising as you go.

Tired with an ultrabook's trackpad, especially with failing trackpad buttons, I decided it was time to finally re-purpose a spare ThinkPad keyboard.

The keyboard I've used is from a old ThinkPad X30.  I needed a keyboard to USB converter.  I happen to have an old USB trackpad keyboard that I wasn't using anymore.  The keyboard has a host board that hooks up to a "standard ThinkPad" keyboard (at that time being any X20/T20/R20/R30 etc), along with a numeric keypad and trackpad.  I'm only going to use the keyboard component.

The controller board in the keyboard case also included a bunch of non-conductive foil that protects the board from pressure exerted by the user on the keyboard.  I decided to use it.

I decided to use a singular colour of block -- red -- as I had a lot of long planks that I could use fairly easily to give the keyboard some stability.  A bottom look of the layout is below:

The base is 40 by 19 blocks.  The height is 2 blocks.

A top view:

I hold together the base planks with various 1/3rd height blocks throughout.  I avoid the placing them in the mid-left area as the controller board will be seated here.  It's a region where I use the longest planks.

Along the inside, on the left and right I place various full height blocks.  The keyboard will rest on these and provide it stability when the user presses down.  The keyboard has a drop down on the right-top side (close to the print screen and page buttons).  I make use of this to lock the keyboard in its place by using a long 2 by 16 block of 1/3rd height.  The middle-top of the keyboard raises up (where the LEDs are), so I raise up by 1/3rd height and place another 2 by 16 block of 1/3rd height to further hold the keyboard.  This piece represents the highest point in the overlay (2 blocks high).

On the bottom I place some "roof tile" blocks (incline blocks).  These are perfect to provide the keyboard a slight slant down for comfort typing, but provide the needed support for preventing the keyboard from sliding.  In the middle-bottom, I extend out a bit with 2 layers of 1/3rd height blocks which will provide support for the trackpoint buttons, preventing them from flexing when pressing down.

The keyboard is in place.  On the left bottom, I ensure the keyboard doesn't move by using a 2 by 3 plank with a "peak roof tile" piece.  I decide to pop the FN key (otherwise the 2 by 3 plank prevents it from working).  I am still able to use the FN key, and for the amount that I use it, it really doesn't matter.  On the right side I place a second "peak roof tile" piece.  It prevents the right CTRL and right ALT from pressing down fully, but the keys do work, just not as comfortable as I'd like.  But these keys I don't use much, so I can live with it.

As you can see, I have it seated on my ultrabook.  I added some extension pieces on right to have it hug the ultrabook completely (so it doesn't slide).

The keyboard and trackpoint are very comfortable to use (believe it or not).

Now a little bit more of the magic that holds the keyboard in place.

A closer look on the left side, you can see a some 1 width blocks that connect to the far left bottom of the overlay.  These allow for room for the USB plug and power plug for the ultrabook.  They box in these plugs, adding support to prevent the keyboard from sliding back and forth.  There happens to be no ventilation holes on this side of the ultrabook, so the blocks with holes are purely decorative.

A closer look on the right side, you can see these "road barrier" blocks that I use to extend out from the bottom right side of the keyboard overlay.  These provide support for the right side of the keyboard from sliding.  They also provide appropriate access to the audio and USB connectors.  I run the USB cable from the controller inside the overlay out on this side as well.

That's everything :)

From an operational point of view, in Windows, the keyboard is detected as USB keyboard.  But if you install the Lenovo USB ThinkPad with trackpoint drivers, it will operate 100% of the function of a true ThinkPad keyboard (trackpoint, all the function keys, volume keys, etc).

In Linux, the keyboard is detected as an Ultranav Lenovo keyboard.  The function keys appear to be working, but I haven't fully tested them all (hibernation, sleep, etc).  Volume buttons work.  The trackpoint of course works, but I have't been able to get the trackpoint middle-button scrolling fully working.  Even on a ThinkPad, it doesn't work out-of-the-box until you've applied the following "fix":

#! /bin/sh

xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 8 1

xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Button" 8 2

xinput set-prop 'TPPS/2 IBM TrackPoint' "Evdev Wheel Emulation Timeout" 200

xinput set-prop 'TPPS/2 IBM TrackPoint' "Evdev Wheel Emulation Axes" 6 7 4 5

Replacing the  TPPS/2 IBM TrackPoint with the correct name, the fix doesn't appear to be having the desired effect.  Once I work it out, I'll post the fix.

The trackpoint sensitivity is also not adjustable.  You normally adjust it on a ThinkPad with:

echo -n 220 > /sys/devices/platform/i8042/serio1/sensitivity

There are no devices with a sensitivity control.

One of the questions you might be asking is what about the pressure on the ultrabook's keyboard and trackpad.  For the keyboard, the machine has a chicklet-style keyboard, and because the bottom of the overlay is perfectly flush, it doesn't press down on any keys.  Further, the trackpoint nor the use of it seems to have an effect (unwanted interaction) with the trackpad.  However, because I can foresee there being  problems, especially with accidentally resting my fingers on the trackpad, I disable them at my desire in Linux by running an xinput disable.  You can decipher the names of these devices by simply running xinput.  The trackpad showed up as a PS/2 Mouse under Virtual core pointer and the keyboard as AT Translated Set 2 keyboard.  I disable them by running xinput disable AT Translated Set 2 keyboard and xinput disable PS/2 Mouse.  My ultrabook also has touchscreen inputs, which are not affected by these changes.  You can substitute disable with enable to undo the changes.  Naturally, if you disable the inputs, they won't remain disabled after a reboot (so either run them again with a script manually or set them on bootup with /etc/init.d/rc.local).

Living with a laptop without a trackpoint or without a middle mouse button [day 1 of 20-days-of-posts series]

I've been addicted to the trackpoint since I started using one in the '90s [I haven't owned or used a mouse on a regular basis since the '90s].  Truth be told, it wasn't even a IBM ThinkPad -- it was a business model HP Omnibook laptop.

If you haven't used one before, you probably wouldn't appreciate what you're missing.  If you are a ThinkPad enthusiast, you probably appreciate the advantages of a trackpoint -- how it allows you effortlessly move around the screen without taking your fingers off the keys or keyboard.

Even on my desktops, I've always used an equivalent USB keyboard with a trackpoint.

The trackpoint has been one of the many features of the ThinkPad that has kept me a consumer of the line over the years.  Even my Sony ultraportable P799 laptop has a trackpoint.

But there is still bound to be a time where I'll need to use a PC or laptop that doesn't have a trackpoint.  The trackpad has become the standard pointing device on almost all laptops and ultrabooks, and there doesn't exist a single ultrabook with a trackpoint.  Further, most trackpads don't feature the third mouse button that the ThinkPads have.  The third mouse button also has proven invaluable, making it critical for a "copy-and-paste" shortcut in Linux or in putty.  The only thing worse with coping with a laptop without a trackpoint is having to also deal without the middle mouse button.

In Linux, there are some options that don't involve using external devices or USB keyboards.  You can remap keyboard keys as mouse buttons.  I personally find I never use the right Alt, "menu" or right Ctrl keys.  The ideal solution, for me, would be to remap these buttons as mouse buttons (left, center, right). 

Not only does this allow provide you with your missing middle mouse button, but it also brings the buttons closer to your fingers since they are keys on the very same keyboard you have your hands positioned over.  Most trackpad buttons after all are located under the trackpad, which is generally the lower end of the bezel, requiring you to remove your hands from the keyboard to use.

With the keys remapped, you can keep your hands close the keyboard.  With this configuration, I typically will use either my thumb or forefinger to navigate the top edge of the trackpad to control the pointer, while I use the three remaining fingers to press the keys mapped to the mouse buttons.  It took me some getting used to, but then again, I never got used to the trackpad even after months of having to deal with one on an ultrabook.

The select-and-hold feels a little "left handed" in this configuration.  On a traditional trackpoint I use my thumb to hold and my forefinger to select, whereas in this configuration I use my thumb to select.

The solution can be adapted to your needs.  If you find it more natural, you can equally just as easy remap the left Ctrl, "Windows" and left Alt keys as moue buttons (left, middle, right).

Solution:

I've created a shell script that I've setup to start on login (in Debian/Ubuntu, can be a script listed in Startup Applications or call the script or commands from /etc/init.d/rc.local):

#! /bin/sh

setxkbmap -layout us

xkbset m

xkbset exp =m

xmodmap -e "keysym Alt_R = Pointer_Button1"

xmodmap -e "keysym Menu = Pointer_Button2"

xmodmap -e "keysym Control_R = Pointer_Button3"

setxkbmap sets the keyboard layout and should be pre-installed in most distributions.  xkbset lets you map mouse buttons to keyboard keys.  It isn't installed by default on most distributions, but is included with most distributions.  In Debian, it is a simple apt-get install xkbset.  xmodmap does the magic of mapping key functions, in this case to mouse buttons.

Pointer_Button1, Pointer_Button2, and Pointer_Button3 represents the left, middle and right mouse buttons.  Alt_R,  Menu and Control_R represents the three keys I discussed earlier.

If the left side of the keyboard is more to your liking (for instance, if you are left handed), then you can use the keys Control_L, Windows and Alt_L key names.

Obviously, the keys remapped will no longer function with their original programmed behaviour.  I found myself only using the left Alt and Ctrl keys, so I never missed the right key equivalents.

Upcoming 20-days-of-posts...

I have a long list of interesting posts that have been peculating for the past few months.  I've decided to get them hammered out and posted in the first "annual?" 20-days-of-posts, which just happens to lead right up to Christmas.

I've decided to leave the titles omitted in the schedule (but I've provided the tags)  so that there is still some mystery each day :) [I'll populate them the days tick-by]

1. Living with a laptop without a trackpoint or without a middle mouse button (linux)
2. ThinkPad keyboard overlay for non-ThinkPads(lego, linux)
3. My original Raspberry Pi server lego case (pi, lego)
4. USB WebMail Notifier (pi, lego, linux)
5. My headless Raspberry Pi server (pi, lego, linux)
6. Adding IR to your Raspberry Pi (pi, linux)
7. ? (pi, xbmc)
8. ? (pi, lego)
9. ? (pi, lego)
10. ? (pi, lego)
11. ? (pi, lego)
12. ? (pi, xbmc)
13. ? (light-side)
14. ? (pi, xbmc)
15. ? (pi, xbmc)
16. ? (pi, xbmc)
17. ? (linux)
18. ? (linux)
19. ? (pi, xbmc)
20. ? (light-side)

First post will be posted tonight.

Google Drive Video add-on for XBMC

Google Drive Video add-on for XBMC

A video add-on for XBMC that enables playback of videos stored in a Google Drive account.

Supports [Tested on]: All XBMC 12 and 12.2 including Linux, Windows, OS X, Android, Pivos, iOS (including ATV2)

*Note for Raspberry Pi users*
: Due to a bug in libcurl with HTTPS streams (Google Drive uses HTTPS only), playback of content on these devices may not work. I have tested on various Raspberry Pi distributions and have personally witnessed about a 90% failure rate for playback of videos over HTTPS.


The plugin uses the Google Docs API 3.

Downloads:
* v0.2.0 - https://github.com/ddurdle/XBMC-gdrive/r...tag/v0.2.0
* master git - https://github.com/ddurdle/XBMC-gdrive


Getting Started: 
1) download the .zip file 
2) transfer the .zip file to XBMC 
3) in Video Add-on, select Install from .zip

Before starting the add-on for the first time, either "Configure" or right click and select "Add-on Settings". Enter your fully-qualified Username (including @gmail.com or @domain) and Password.


Features and limitations:

- will index videos in your google drive account, sorted by title name
- folders are ignored but the files contained in them are indexed for playback
- only indexes and playback videos; no pictures at this time

Modes: 
1) standard index
- starting the plugin via video add-ons will display a directory containing all video files within the Google Drive account or those that are shared to that account
- click on the video to playback
- don't create favourites from the index, as the index will contain a URL that will expire after 12-24 hours 

2) mode=playvideo
- you can create .strm or .m3u files that run Google Drive videos direct
- create .strm or .m3u files containing the following: plugin://plugin.video.gdrive?mode=playvideo&title=Title_of_video
- if your video is composed of multiple clips, you can create a .m3u that makes the above plugin:// call, one line for each clip. You can then create a .strm file that points to the .m3u. XBMC can index movies and shows contained in your Google Drive account by either a .strm containing a single plugin:// call to the video, or a .strm that points to a local .m3u file that contains a list of plugin:// calls representing the video

FAQ:

1) Is there support for Google Apps Google Drive accounts? 
Yes. Use your fully qualified username whether that is username@gmail.com or username@domain

2) Is there support for multiple accounts? 
Sort of. For now, you should share all your videos from subsquent Google Drive accounts to the main Google Drive account that you use with this add-on. The shared videos will appear in the index and are viewwable.

3) Does thie add-on support Pictures or other filetypes? 
Not at this time. I had no need for viewing files other then Video, therefore, the initial public release features only the features I have been using.

4) Any limitations? 
I've tested the add-on with several Google Drive accounts, including one with over 700 videos.

Current Version: v0.2.0
first public release


Roadmap to future releases:
- support for multipel Google Drive accounts
- support for OAUTH
- support for pictures
- support for caching account contents
- support for folders and pagination (crucial for accounts with thousands of videos)