Recovering Vista ICM devices.tar.gz and style.tar.gz

September 22, 2012 07:32 by docbliny 

Several people reported that they had attempted to use the auto-update feature in the Vista ICM, and that doing that had removed the files required to display devices.

It seems the auto-update procedure is buggy and erases the flash storage before checking if it’s able to successfully load any available updates. Since the device has been discontinued and (I think) In2Networks has gone out of business (or at least has shut down the related servers). This means that the auto-update feature is now an “auto-destruct” feature.

My ICM was still intact (though I did have to factory reset it since it wasn’t responding), I did some hunting and pecking, and in the end I was able to pull out the files from flash file. I’ve attached them below. You can use the Advanced / File System page to upload and save them to flash under http://[ipaddress]/setup. As usual: Use at your own risk.

Thanks to Norman for agreeing to be the guinea pig to test these files out!


Now for some geeky stuff:

1. To download files from the device, you can create files in the /var/fusion/web folder. The other option is to create a symbolic link to an existing file. This is especially useful for larger files. You can then download the file(s) with a browser from http://[ipaddress]/web/[filename].

2. I wasn’t able to download all of the flash files. In any case they are in /dev/flash:

  • all
  • boot
  • bootarg
  • config
  • ethmac
  • image
  • settings
  • storage

The reason I couldn’t get some of the larger files out is that the embedded shell does not support IO redirection, so I couldn’t cat to gzip to minimize the size.

3. I pulled the devices.tar.gz and style.tar.gz out of a flash image located at /dev/flash/storage. Since they were combined in a flash image, I had to remove a few bytes of the header before the first gzip file, and then split it into two (one for styles and one for devices). A test with 7Zip on Windows said the files were valid. I was also able to use gunzip on the ICM to extract the contained tar. However, tar failed as it ran out of space about halfway through (normally they packages are on another disk so the extraction works when it happens on startup.

Hack of the Day: QClock

July 21, 2012 11:22 by docbliny 

I spent a moment this morning slapping together another application for the Nexus Q. This one is really simple, and all it does is to use the LEDs to show the time. There are three “hands” that show the hour in white, minutes in blue, and seconds in red.

The video doesn’t do full justice to the ability to read the time. The camera picked up too much light around each hand due to the diffusion the LEDs have. For example, the second hand looks fully red in real life, and doesn’t have the rainbow band around it as seen on the video.

QRemote REST API Documentation

July 14, 2012 19:20 by docbliny 

The QRemote REST API documentation is now bundled into the application itself, but here’s a copy/paste for reference.


QRemote Source Code Now Available

July 14, 2012 19:10 by docbliny 


I just finished setting up a repo on GitHub for QRemote:

It includes the source for both the Android application and the web interface.

I also updated the installable APK with the rough API documentation.

QRemote Nexus Q Application

July 8, 2012 06:11 by docbliny 

UPDATE July 14, 2012: I updated the APK to contain rough API documentation. Just navigate to adjusting the IP address to match your Q.

OK, it’s late (I mean early), but here’s a very rough alpha version of QRemote which let let you control the Nexus Q via a RESTful-ish API and your web browser. It’s developer-only friendly at the moment, but that shouldn’t a problem since only Google I/O attendees have them. If you’re brave enough to test it and have feedback, hit me up via Twitter, Google+, or email. I’m lazy at approving comments here on the site. Anyway, to the point…


Here it is in all it's glory.



  • Download QRemote.apk here.
  • Upload the file using adb with the following command: adb install QRemote.apk


Unfortunately, you’ll have to manually start the application every time you power on the Nexus Q. I’m working on to get the boot message receiver to work with a signed package (seems to work fine with a debug build).

  • Start the application with the following command: adb shell am start -a android.intent.action.MAIN -n
  • Open up a browser and navigate to port 8080. For example,

Known Issues

  • You need to start it manually every time you power up the Nexus Q.
  • You have to know your Q’s IP address.
  • You need to load up a playlist with the Play application on an Android device.
  • Videos are not supported.


  • Run the following command: adb uninstall


You will need to uninstall and re-install the application if you had the initial Alpha version as I changed the keys used to sign the application. Just follow the instructions above to uninstall and install again.

Teaser: Controlling Nexus Q LEDs over API

July 5, 2012 18:58 by docbliny 

The video says it all.


Remoat Home Automation Software

June 30, 2012 17:31 by docbliny 

Since I missed the May Home Automation Month, I really need to make up for it somehow. So here’s a quick video of Remoat (, a little utility I’ve been putting together in my spare time. It’s not really production-ready, but I’ll make the source available for the hackers out there.

Currently it needs/supports the following:

  • Windows Media Player: Plays music from your library.
  • MiCasaVerde Vera: Allows you to turn on binary devices, such as lights that you’ve got configured.
  • mControl 2.X: There’s some old code in the package from when I was running mControl on my WHS box (which had sequential disk failures and in the end killed my RAID –> switched to a QNAP NAS). Unsupported.
  • Windows Vista/7 speech recognition: This is required (part of the operating system anyway).
  • Windows text-to-speech: You can specify which audio device is used for speech output. This lets you hook up a pair of speakers that are always on and have the PC hooked up to you’re a/V system for better quality playback. Part of the operating system.

Yamaha RX-V3800 Remote Control Plug-In for Vera

June 30, 2012 11:44 by docbliny 

OK, so I started “home automation month” last year in May then went ahead and immediately missed it this year. To make up for this grievous error, I put together a plug-in for the Vera home automation device that allows you to remote control a Yamaha RX-V3800 receiver.

You’ll need a Yamaha RX-V3800 A/V receiver (or compatible unit, such as the RX-V1800 or HTR-6190), an Ethernet-to-serial adapter to hook it up to your network, and of course a Vera unit.

The download and additional information can be found on the project page at .

Home Automation History Month

May 22, 2011 16:06 by docbliny 

It’s May which equates to Home Automation month. OK, I just made that up, but it is somewhat fitting since Google announced Android@Home this month, and the last version of VoiceShell for the Commodore Amiga I published is dated May 2nd, 1996.


VoiceShell was my speech recognition application that could be trained to understand up to 60 different phrases and run a different command for each. With the magic of ARexx, a scripting language that allowed communication between applications, I was able to send commands to other applications. It also allowed me to switch vocabularies to both extend the available number of commands, and to maximize the recognition accuracy (today I can simply construct a hierarchy of commands using SRGS XML files).

Here’s the description from the Hyperlinked documentation:


This program is a 'replacement' for VCLI. It doesn't have the fancy graphics etc. but it seems to eat less CPU time and should be faster overall. It also has some extra options.

"So what is VCLI?" I hear you ask. VCLI is a program by Richard Horne that uses his voice.library to recognize speech. With VCLI and VoiceShell you can start programs by saying the program's name. You can teach VoiceShell 60 (VCLI allows 48) different words. You also have the possibility to load a new set of words, thus giving limitless possibilities. The more words you teach, the less accurate the result will be. Thus having more than one project might be a good idea. All you have to do to get started is to set the correct preferences, teach some words, set the commands and away you go!

Of course, like everything I wrote back then, this was written using assembly language for the Motorola 68000 series CPU. The application had an installation utility, hyperlinked documentation, support for startup arguments for both Command Line Interface (CLI) and Workbench icons, ARexx scripting interface, and hotkey support. I know it got published in at least one Amiga magazine on their floppy disk (I believe in the U.K., but I’d need to dig up the copy they sent me) and was available on the Internet as early as 1993. I had at least 26 releases with incremental feature additions and bug fixes.

I was contacted by Alex C. last year to get a copy of the source code and there is a thread on discussing adapting it for the current crop of emulators and Amiga OS versions. It’s amazing how code will live on!


Of course, VoiceShell was only part of the picture. CompleteControl was the software part of the automation suite that controlled devices via relays. It comprised of a set of ARexx scripts, sounds, images, and an application that would run on a MS-DOS PC. These applications, along with an Input/Output board and a custom power strip, would allow me to turn on and off devices such as lamps. I even rigged a relay into my bedroom light switch, so that I could turn it on and off.

It was a total hackfest with a lot of moving pieces: Custom PCBs, two computers (an Amiga and a PC), sound sampler dongle, a custom power strip, custom DB9 cables, an I/O card, voice recognition, custom sound samples for responses, and hardware control software. But hey, it actually worked!

Present Day

There have been many iterations on the same basic premise over the years. I’ve cobbled together various X10 and ZWave solutions with PCs using custom and off-the-shelf software over the years. The current project is named “Remoat” and it’s in a prototype stage controlling lights in the whole house along with supporting media playback. It’s a labor of love that has had to take the backseat over the past several years, but the goal is to evolve it further and make available online.


Screenshot of the VoiceShell Application

Screenshot of the VoiceShell application

VoiceShell Hyperlinked Documentation

VoiceShell hyperlinked documentation

PCB Board Image Opened In DeluxePaint

PCB Board Image Opened In DeluxePaint

System.Speech.SpeechRecognizer works, SpeechRecognitionEngine doesn’t

April 24, 2011 08:53 by docbliny 

I believe I've found an issue with the managed speech recognition libraries. The short problem description is that I am unable to use SRGS/.grxml files that contain "ruleref" elements pointing to other files with System.Speech.Recognition.SpeechRecognitionEngine (InProc). They load fine when using SpeechRecognizer.

After debugging (and finally making a custom build of System.Speech.dll), I've narrowed down on the issue. When you use an InProc recognizer, RecognizerBase.cs sets a custom grammar loader (ISpGrammarResourceLoader). Unfortunately, the RecognizerBase.LoadResource method that is used will receive a null value for the last argument ("pbstrRedirectUrl"), and cause a null exception when it tries to do a split on the null string. This also explains why SpeechRecognizer does not have any issues with the same files.

The same issue happens with both 3.5 and 4.0 versions of the Framework.


I can’t get a speech recognition project I started in 2008 to correctly load the grammar definition files (.grxml / SRGS) in my current environment (Windows 7 64-bit) with SpeechRecognitionEngine.


Well, turns out that the shared SpeechRecognizer will correctly load the exact same GRXML files with external ruleref definitions. After hunting through the .NET source code, the culprit might be in the RecognizerBase.cs method named LoadSapiGrammarFromCfg(). It sets a custom grammar loader for SAPI only when using an InProc recognizer (which SpeechRecognitionEngine is). The comments even state “The rulerefs will be resolved locally.”

So, I have the following options:

  • Continue debugging .NET to see if the behavior has changed, and I’m simply missing some element in the XML file. This doesn’t seem likely, as ProcMonitor clearly states that only the first file even gets a open/read attempt. I’ve tried setting the base URI, used absolute paths, did a quick attempt at loading from a URL. The problem is made worse by the fact that I can’t step through the .NET code in either Visual Studio 2008 or 2010. Fixing that will take its own time… I could try using the .NET Framework code (fingers crossed all the required files are available) directly.
  • Switch to using SpeechRecognizer. I don’t want this, because I’d end up with a broader dictionary which will reduce accuracy.
  • Merge my GRXML files. Yuck. There’s a reason for ruleref support in the files. In addition, the app is meant to be extensible, and having to merge files just makes things harder for the developer and end users.
  • Go down the path of using SpeechLib/SAPI, but looking at the amount of code in the Framework, this seems totally redundant.

Error Info

  • SapiErrorInvalidImport A rule reference to an imported grammar cannot be resolved.
  • 0x80045024
  • -2147200988