[wish-info] USB Powerlinc (V1) extended codes

Ardian Dhrimaj

2007-07-01 16:36:07 UTC

Hi Scott,

Thanks for responding. No problem about the delay...

I managed to sign up already and also submitted a patch to Sourceforge.
(the posting should show up under the ard_pangalactic SF account name).
I'm not sure if the patch format is correct - first time I'm
contributing something to SF.

Regarding incoming extended messages: The code for extracting the
extended X10 code from the USB packets and translating that to parsed
fields in a structure is already in place in the patch mentioned above.
I just don't know how to expose that info to the user mode apps. An
extra device that can be only read from might do the trick. Maybe
/dev/statusraw. The format would probably be similar to sending extended
commands. I currently just print something like this to the kernel
message queue:

Jul 1 12:31:49 mpl plusbd[4662]: received data - decoding: 40 60 e6 96
a9 a6 55 55
Jul 1 12:31:49 mpl plusbd[4662]: Decoding extended message - signal
strength: 60
Jul 1 12:31:49 mpl plusbd[4662]: received data - decoding: 40 00 6a 57
9a 5a a6 99
Jul 1 12:31:50 mpl plusbd[4662]: received data - decoding: 41 00 55 55
a9 50 00 00
Jul 1 12:31:50 mpl plusbd[4662]: Decoded extended message:
Jul 1 12:31:50 mpl plusbd[4662]: hc 6 ;
Jul 1 12:31:50 mpl plusbd[4662]: cmd 7 ;
Jul 1 12:31:50 mpl plusbd[4662]: c_u 1 ;
Jul 1 12:31:50 mpl plusbd[4662]: uc 6 ;
Jul 1 12:31:50 mpl plusbd[4662]: data 80 ;
Jul 1 12:31:50 mpl plusbd[4662]: ctype 3 ;
Jul 1 12:31:50 mpl plusbd[4662]: ecmd 8 ;
Jul 1 12:31:50 mpl plusbd[4662]: Error: Extended data not supported

I haven't had time to play with this recently. Hopefully I can get
Misterhouse to interface with the driver at some point.

/br,
Ardi

Post by Scott Hiles
Ardi,
Somehow this message was stuck in queue and I never approved it. I was just
checking through status of things and happened upon it.
I have been very inactive in development since I broke my back this year.
Just getting back into the swing of things now.
Anyhow, if you would like to contribute your code to the drivers, the
community would be very happy to have it and could probably improve on it.
Join the mailing list and apply to be a developer on the project and I will
add you to the project for you to make your changes.
As for the decoder...I know that the logic in the status mechanism is
difficult, but it all based on trying to queue things between the dev driver
and the usermode application. It isn't until the usermode application that
any translation is done and the raw data is spit into the status queue. The
x10log program decodes the raw messages into readable information.
Scott
-----Original Message-----
Sent: Monday, May 07, 2007 9:05 PM
Subject: USB Powerlinc (V1) extended codes
Hi folks,
I have modified the 2.x drivers for the USB Powerlinc (I have an 1132U)
to add limited support for extended code commands (ext code 1 - for data
/control; NOT extended data). I'd like to submit the changes for
review/testing but am new to sourceforge in general and have no idea how.
I only have a couple of LM14s (2 way lamp dimmers by X10) and that is
all I could test with. The changes allow the user to send an extended
$ echo EXT 3F31 > /dev/x10/a1
where 3f is the data byte, 3 is the command type, and 1 is the extended
command itself. The data format is spelled out at
ftp://ftp.x10.com/pub/manuals/xtc798.doc. The command above for example,
means "Turn on immediate at 100% brightness".
I did this because I use the extended commands to setup a lamp as a
morning alarm. Turn on at minimum brightness no matter what the previous
state, then ramp up slowly to max.
I also implemented a decoder for extended code responses, but have only
tested this with the above mentioned LM14s. Also, given the way the WISH
drivers currently work, I have no idea how to report that status back to
user mode applications - it just generates some prints to /var/log/messages.
My work is based on Ubuntu Feisty.
/br,
Ardi