USB-UIRT and IR control

Limitations:

1.  Can't receive on Windows at all (no state matching, no learning.)  I wrote a "helper" app for this in VB last August, but have since appropriated it for my commercial project.  All I ever heard after I announced the existence of this thing last summer is "We locked out your updates from the test version, will you please upload them somewhere else so we can still have them."  In a word, no.  The test version is for testing.  These people
don't get that.  They are scared to death to change anything in the test version because there is an army of hyperactive geeks that constantly download it (and scream bloody murder when things break.)  Not much use as a test version under those circumstances.  No wonder this thing is such a mess.

2.  Can receive on Linux, but no state matching (see below.)

3.  Can't learn on Linux (that code is dead weight.)

From the comments at the top of the module:

Transmitting

Use the web interface generated by USB_UIRT_learning.pl to learn and import codes.  Then create
your own code file that uses IR_Item to transmit.

$TV  = new IR_Item 'SONY TV', 'addEnter', 'usb_uirt';

my $tv_states = 'power,mute,vol+,vol-,ch+,ch-,2,3,4,5,6,7,8,9,11,13,14';

set_states $TV split ',', $tv_states if $Reload;
$v_tv_control = new  Voice_Cmd("tv [$tv_states]");

# Okay, but WHY would they force you to write code to populate the states?
# These states (except for the channels above 9) are in the IR database (populated by that
# Web form that opens new windows constantly.)
# I remember when I first tried this thing "as is" and did something like:
# set $tv '101' and it crashed Misterhouse. (!)  Should obviously be able to figure out
# that '101' means send 1 then 0 then 1.  That would be nice (as opposed to crashing MH!)

if (($state = said $v_tv_control)) {
        print_log "Setting TV to $state";
        set $TV $state;
}

# That print_log should be a respond method call, but that's another story.

Receiving

Not implemented on Windows.  

# Oh well.  Looks like it never will be unless you buy my app.

This module will report incoming infrared signals in the Misterhouse log output.  You can use
these signal codes to create triggers that can control your MP3 player, DVD software, etc.
To use this feature, add lines like these to your code:

$remote = new Serial_Item '190003A0A0E2', 'play';
$remote->add              '190003AEB012', 'stop';

if (my $state = state_now $remote) {
        set $mp3 $state;
}

# In other words, the author was too feeble to finish what he started.  Those twelve digit codes are examples
# of USB-UIRT structured format.  They are good for receiving only (ie you won't find them in the IR database.)
# The big clue is that the two formats that are stored in the database are easily converted to this abbreviated
# form.  Easy is relative of course.  The sample code in the USB-UIRT SDK didn't have it right at the time I wrote
# my treatment.  I informed them of the mistake and they said they would fix it.

The two "expanded" formats (read: can be used for transmitting) are called "raw" and "Pronto."  The conversion process looks like:

Pronto -> raw -> struct

Or just raw -> struct if the code in the database is already raw.

There is a pronto_to_raw and a raw_to_struct in there, but the latter is never called.  I doubt it would work anyway as this stuff was written back in 2002, long before the SDK mistake was discovered.

It should be patently obvious what is supposed to happen here.  It is about a one hour exercise.  I did it last August and was quite happy with Misterhouse and IR control until I scrapped Misterhouse completely in December.  Here's a basic road map:

1.  Load the states into a hash on startup, indexed by the structured codes.  Realize that most IR codes have TWO of these structured codes (a head and tail.)  Make a key out of them like this:

190003A0A0E2|190003A0A0E2 (note the head and tail are not identical in real world examples.)

2.  When you receive one of these things, try to look it up in the hash (usually won't find it as most codes have a tail.)  If not found, stash the code until the next one comes in (very similar to the X10 multikey logic.)  Once you have a combined code that matches, try to match the device from the database to an existing IR Item.  Got one?  Match the state.  Got it?  Now your IR items are logged just like everything else and you can write code like:

if (state_now $preamp eq 'video2') {
      set $tv 'input1';
      set $receiver 'dolby digital';
      set $blinds_motor 'on' if $blinds->{state} eq 'open';
      set $dvd_player 'play'; # WinDVD module
}

Currently code like this will only run if you set the IR Item in code, from the Web, tk, etc.  NOT when you press the button on the remote from the couch.  Guess they never thought of that.

Since IR Items are already xAP-enabled, it isn't hard to figure out how to use your LAN to route these signals around the house.  One issue with that is that the xAP IR Items are (inexplicably) case sensitive.  It doesn't matter what xAP can do, MH IR is not case sensitive (per the database.)  So get that one line out of there that sets case sensitivity.  Then xAP and USB-UIRT IR Items will be on equal footing and progress can take place...

Here's a switch: I have locked MY repository.  I could be convinced to unlock it if there is progress made in the "official" version.  Without such progress (eg the case-senstivity issue here, the stupid Web scripts, X10 incompetence, etc.), merging the two versions is impossible.  Get it?  Now lets see how many more years go by before they figure this out.  The original module came out in 2002 I think.  Ironic that the guy who wrote it is one of the over-protective little pukes guarding the repository.  What are you guarding stupid?  You haven't made an inch of progress in five years.  If you look at his code carefully, you can see exactly where he got confused and gave up.  What a bitch!  Not just because he quit, but because he won't let anyone else step in and finish.  That's a loser for you.