USB-UIRT Plugin

[Brandt]

I have the USB-UIRT (http://www.usbuirt.com/) that I was previously using with Linux and LIRC. I would like to be able to use it with Indigo, rather then throw it in the junk bin and buy the IRTrans, EZUIRT, or IRLinc. Someone has written a small binary in order to make it work on a Mac called Ribsu (http://www.xyster.net/ribsu/), but I would like to take it a step further and see an Indigo plugin for this device. I am only restrained by time and knowledge of Python at the moment, but if anyone else is interested maybe we could work together. The USB-UIRT works great with a set of those X10 Powermids to distribute the signal throughout the house.

[Brandt]

Here is the source of a python script somebody wrote for the USB-UIRT:

https://github.com/BenSmith/python-usbu ... usbuirt.py


However it requires a shared object library file, which is for linux...no one every implemented a Mac OS X library for this device.....Would someone here know how to do it if I got all the documentation from the products developer? He also has a partly developed library for the Mac, just needs to be finished.

[Brandt]

Here is the command protocol document.

http://www.usbuirt.com/USB-UIRT%20Comma ... otocol.doc

[Brandt]

wooo I was able to see something using my non existent python skills in the scripting shell:

Code: Select all

import serial
ser = serial.Serial('/dev/tty.usbserial-0000103D', 125000, rtscts=True, timeout=5)
line = ser.readline(size=None,eol='\xff')
num = int(line.encode('hex'),16)

ser.close()

[Brandt]

What is a good way in pyserial to grab data byte by byte until it sees a termination byte of '0xFF'? I would think a loop, but is that ideal in a plugin environment?

[Brandt]

Can anybody help with this?

I'm trying to get the firmware version from the USB-UIRT. It says to get the version you send the byte 0x23 + checksum. At the bottom of the protocol doc it says the command byte plus the checksum must equal 0x00 or 100. so it should be 0x23 + 0xdd.

now how do I sent these bytes? I swear i've tried everything and it always responds with '\xfe' which I think is a question mark.

It should respond with 8 bytes:

Code: Select all

GETVERSION = 0x23 + checksum
On this command, the USB-UIRT will send 7 bytes of version info followed by a checksum byte, as follows:
Byte 0: Firmware MinorVersion
Byte 1: Firmware MajorVersion
Byte 2: ProtocolCompatibility MinorVersion
Byte 3: ProtocolCompatibility MajorVersion
Byte 4: FirmwareDate Day
Byte 5: FirmwareDate Month
Byte 6: FirmwareDate Year

I've tried:

ser.write(chr(0x23)+chr(0xdd))
ser.write('\x23\xdd')
ser.write(struct.pack('c', 0x23, 0xdd))

getting frustrated here.

EDIT: I came across a forum post on there...apparently the protocol doc is out of date, he gave an update in the forum post. Unfortunately the hardware developer is not very responsive:


http://www.usbuirt.com/phpBB2/viewtopic.php?t=25


>>> ser = serial.Serial('/dev/tty.usbserial-0000103D', 312500, rtscts=True, timeout=5)
>>> ser.open()
>>> ser.write('\0x23\0xdd')
8
>>> ser.read(8)
'\x01\x01\x1a\x03\x04\xcf\x80\x81'

[Brandt]

looks like i'm getting better results with this:

Code: Select all

>>> ser.write(b'\x23\xdd\xff')
3
>>> ser.readline(ser.inWaiting())
'\t\x05\x01\x01\x1a\x03\x04\xcf'

I don't know what \t is besides escape code for tab....but according to the above breakout it would be:

Byte 0: Firmware MinorVersion - \t ??
Byte 1: Firmware MajorVersion - 5
Byte 2: ProtocolCompatibility MinorVersion - 1
Byte 3: ProtocolCompatibility MajorVersion - 1
Byte 4: FirmwareDate Day - 26
Byte 5: FirmwareDate Month - 3
Byte 6: FirmwareDate Year - 4

Which I think translates to
F/W version 5.?
Protocol Compatibility Version 1.1
F/W Date 3/26/04

I'm guessing that's accurate after some of the posts i've read on the ghost town usb-uirt board.


EDIT:

Ah, here we go:

>>> s = ser.readline(ser.inWaiting())
>>> print ord(s[0])
9
>>> print ord(s[1])
5
>>> print ord(s[2])
1
>>> print ord(s[3])
1
>>> print ord(s[4])
26
>>> print ord(s[5])
3
>>> print ord(s[6])
4
>>> print ord(s[7])
207

[Brandt]

Finally making some head way....got a basic script that can talk to the USB-UIRT itself....I've also figured out how to receive RAW IR.....next step is to figure out how to transmit.

Here is some output from my python script so far:

Code: Select all

Connected to /dev/tty.usbserial-0000103D

USB-UIRT


Getting Version Information...
Firmware Version: 5.9
Protocol Version: 1.1
Firmware Date: 2004/3/26

Getting Configuration...
LED Blink on IR TX
LED Blink on IR RX

Setting RAW Mode...
CMDOK

Ready to Receive...
239422282371358838963257899305326620367028738232672533642442506466225620746

[Brandt]

My proof-of-concept script for the USB-UIRT using Python with PySerial is coming along nicely. I am able to do all the basic functionality. I guess the next step is to make it interactive, and then begin transforming it into a plugin.

Here is my script output this far:

Code: Select all

Connected to /dev/tty.usbserial-0000103D

USB-UIRT


Getting Version Information...
Firmware Version: 5.9
Protocol Version: 1.1
Firmware Date: 2004/3/26

Getting Configuration...
LED Blink on IR TX
LED Blink on IR RX

Setting RAW Mode...
CMDOK

Ready to Receive...
8635691865349200644467935384023306499274569272471870077160380963101760828397790226810293949202586529252746809039266077736188788599220915
4642033268688680052671589668126906656952502636014362965177129226404135593802122495669859479752684550779924236899365804510386591042039260
4378890434611469131594938927068445034077217531056414307406821543210196656998680894071366955434743775177653481877423608579376539946979565
01671760153002273808723771283347703813583601707955116251903

Ready to Transmit...
Transmitting...

Closing connection...

Done.

[matt (support)]

I didn't read over the protocol document, but a couple of suggestions:

Check the length of the string read by readline() to confirm that it has the number of bytes you are expecting. If it doesn't, and you try to access that byte (ex: s[7]) then you'll get an exception thrown. So I would do a sanity check on the number of bytes expected, and if it doesn't match I would wait for half a second or so then call flushInput(). The idea here being that if the protocol responses get delayed, out-of-sync, or corrupted somehow, that you can just flush the buffer to try to get back in-sync.

The other suggestion is to use the plugin's openSerial() method instead of pySerial's. It takes the exact same arguments, except for an additional first one that is the owner's name, which would be either your plugin's name or the device's name depending on how the plugin is written. Example:

Code: Select all

conn = self.plugin.openSerial(dev.name, portName, 9600, timeout=1, writeTimeout=1, ...)

The difference between our version of openSerial and pySerial's is that our version never throws. If there is an error of any type then the error is logged to Indigo and None is returned. So you (the plugin caller) would want to in this case make sure conn is not None before proceeding. If you use pySerial's version then you'll need to add your own exception handling and error logging.

[Brandt]

Thanks, I've combed through the EasyDAQ.py file and I've made appropriate code changes so the code is more similar...

[Brandt]

Ugh, I've hit a road block in development for now ...here is what the USB-UIRT hardware developer told me:

Brandt,

The short answer is that it is *not* trivial to capture a code and prepare it for transmit. Sure, you can send out the same IR timing you receive, but it usually doesn’t work well. Most learning devices perform a lot of filtering and averaging to produce a ‘clean’ code. Also, the RAW mode you are using on the USB-UIRT to capture the code does not contain enough timing and carrier information to produce a code – you would need to use an even lower-level capture mode which uses the LEARN sensor on the USB-UIRT (the LEARN sensor is a special short-range sensor which only has a range of 1-2 inches but can capture all of the details of IR energy).

The OSX library provides the same basic API as the Windows/Linux library. The complication is that there is no installer at present for this library.

Jon

Then he provided me with a semi complete library for the mac and said this:

Here’s what I have for OSX. This was done quite some time ago but was tested on OSX. I have attached an old framework as it was installed on my machine and an old library installer I had created. You probably want to go the framework route and copy the framework files into the right locations. Unfortunately, I am not a lot of help in the right way to do this, since I am not all than OSX savvy.

There is also an Xcode project for a program called trydrv which exercises the various parts of the API.

I only have XCode experience with iOS development, I'll see what I can make of it but no guarantees...

[Brandt]

okay! progress has been made!

I checked out the driver, but I don't think I'm going to use it! It's not very portable, and would add extra headaches for users.

That being said, I found out how you get the USB-UIRT into low-level mode RAW2 in order to use the LEARN sensor which only works with the remote about 2-4 inches away. I also just thought of a second use case which was a huge 'DUH!' on my part. Originally I was thinking I want to receive a LONG IR data stream using the LEARN sensor in RAW2 which can pick up on frequency variations. with this first use case I would then have to do a bunch of math calculations, and filter, average, and compress the RAW2 payload to get it ready for re-transmitting to turn on/off IR devices. The second use case I overlooked was to just capture a RAW(1) code which doesn't contain as much data, but can still be compared over a few 'recording' attempts to capture the best match, and then use that code to turn On/Off an Insteon device. The processing of RAW2 IR data for transmission is REALLY difficult so I am going to focus on my recently realized use case in order to toggle Insteon devices.

Another suggestion the USB-UIRT manufacturer made to me was to convert the RAW2 data to PRONTO codes, and match them up with a vast database of them available on the Internet for easier programming. Then I could just take the PRONTO codes and convert them back for re-transmission of the payload.

I would say go ahead and add this one to the Plugin wishlist because it is slowly becoming a reality...

[jay (support)]

I've moved this entire topic to the "Plugins in Development" section. I'll add it to the wish list and point it here.

[Brandt]

Jay,

I noticed indigo.server.log couldn't handle this:


print (u"\tLED blink on IR TX: "), "yes" if (ord(data[0]) & 0x01) == 0x01 else "no"
print (u"\tLED blink on IR RX: "), "yes" if (ord(data[0]) & 0x02) == 0x02 else "no"

in the form of:

indigo.server.log(u"\tLED blink on IR TX: "), "yes" if (ord(data[0]) & 0x01) == 0x01 else "no"
indigo.server.log(u"\tLED blink on IR RX: "), "yes" if (ord(data[0]) & 0x02) == 0x02 else "no"

got it to work like this:

indigo.server.log(u"\tLED blink on IR TX: %s" % ("yes" if (ord(data[0]) & 0x01) == 0x01 else "no"))
indigo.server.log(u"\tLED blink on IR RX: %s \n" % ("yes" if (ord(data[0]) & 0x02) == 0x02 else "no"))