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 (http://remoat.com), 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.

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

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:

WHAT DOES IT DO?

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 AmigaWorld.net discussing adapting it for the current crop of emulators and Amiga OS versions. It’s amazing how code will live on!

CompleteControl

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.

Screenshots

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.

Problem

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.

STATUS

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.
  • SAPIErrorCodes.SPERR_INVALID_IMPORT
  • 0x80045024
  • -2147200988

Why does System.Speech.Internal.SrgsCompiler.CompileStream() default to “es-us” CultureInfo?

April 23, 2011 09:16 by docbliny 

UPDATE: Nevermind, this is a patch for the "es-us" culture which has the ID 0x540A.

I been trying to track down why I can’t get GRXML files that have ruleref elements pointing to external files working with Windows 7 (64-bit), and ran into the following line of code:

culture = (backend.LangId == 0x540a) ? new CultureInfo("es-us") : new CultureInfo(backend.LangId);

Note the "es-us" locale. Weird. Now back to banging my head against the original problem.