It took a bit longer to get my TSU9600 and get some time to play around with it than I had hoped. But today I managed to get some free time to check out the protocol the TSU9600 uses when talking to the extenders and I have happy news for everyone!

I managed to figure out part of it. Enough to fake a RFX9600 and get the RS232 commands! The best part with RS232 commands is that they are sent in clear text so we can add anything we want in the pronto editor and get it on a computer of our own choice.

So far the program dumps all packets it gets and can also respond to some commands. It can also act as a proxy between the TSU9600 and an extender. The packet dumping might help people analyze eventual connection problems they have.

It seems like the 'SendIR' packets use some nonstandard format. I'm not sure if its the new superhex format or if they have RLE encoded the data. So if we want to simulate a TSU9600 (instead of an extender) we would have to capture the packets and resend them as needed. However if that's done then we can for example turn on our HIFI equipment from any computer.

I'll see if I can't put together a "trigger plugin" to homeseer so we can control everything homeseer can using the TSU9600 or how does controlling you X10, Z-Wave or whatever system using the TSU9600 sound? =)

Lastly, Thanks Philips for this wonderful remote!

Do you have any source code or documentation that you could share privately via email? I'd love to see what the protocol is like.

That sounds very interesting, I get phone calls at work asking how to turn this and that on and off. I have had a harmony remote to get me by before the 9600 arrives and she has no idea how to work it.

I just put up a page with the analyzer program on for the ones that have nothing better to do than watch pronto packets. It could possibly also help you if your having connection problems and have tried everything else to help figure out whats wrong. Using this you should at least be able to see if any Pronto Pro commands gets out onto you wired network.

The program is called Prontonic

Time to get back to working on the Homeseer plugin module.

Excellent work Xetick, we've just added Prontonic to our News page. Looking forward to the HomeSeer development!

M.

Nice work... thanks for sharing. Now, if Philips would just be a bit more forthcoming with the integrators without having to figure this stuff out ourselves. Think of all of the nice widgets they'd have by now if it were an open/semi-open platform.

I had written a quick and dirty two part packet sender/receiver app to analyze the Escient/Pronto interactions in order to eventually emulate an Escient to the Pronto in a future windows app.

You might want to add this feature to your app as it is the only other device talking over the network. Perhaps a complete proxy that analyzes the data as it is passed back and forth like you appear to be doing with the RFX.

If you open your source or want a hand I program in C#/.NET as well.

Sounds like a good idea and a fun project to do however the Escient talk using a completely different protocol than the Pronto does and seeing as I don't have one I will have a very hard time adding it.

Currently I don't have any open source plans because the code doesn't look as nice as I want it. However that might change in the future.

The Escient Control Protocol is available here: [Link: escient.com]

However, the protocol doc doesn't really give any concrete examples of "conversations" between the Escient and the control device. SO, adding a bit that just spit out the commands (to be interpreted via the the aforementioned manual) to see an entire conversation like you are doing now would be a very nice feature.

It doesn't seem to be much point in writing a proxy for the escient because we have what we need. That is the manual for all the commands. "All" we will need to do is to let the pronto send commands to our music server and let us respond to them. I'm currently up to responding to the database commands but the question is where do we get this information. I was thinking about getting it from winamp but can we even get at the playlists? What was your plans?

Something like WinAmp or even WMP might do for collecting data. If not, even parsing the data yourself might work given a music share and correct mp3 tags.

I was thinking of parsing realtime XM data that I can aquire from an ADA XM brick however and insert the stations as artists or albums and updating the current songs every few minutes. But, I figured it might not work as the refresh time on aquiring data might be fixed.

BTW, did you collect any of the response codes from serial commands... I see that just sending out a serial command and not sending a response results in an error in the Prontos diagnostics when using Prontonic in Simulator mode. However, I don't have a RFX9600 connected to see what a proper positive "received command" looks like in Proxy mode, so some assistance would be appreciated.

I think my first project will be to control some ADA (multizone amp, tuners) gear completely over one way IP, taking the Extender out of the mix as the gear is controllable via serial commands over IP. So, I figure a little clean up of the packets from the Pronto and sending it to the correct IP:port for the ADA equipment I'll have a all IP system going through a PC based proxy.

Ok you misunderstand me. With a proxy I mean something that just looks at the packets and forwards them to a real device. Like Pronto<->Protonic<->Extender or Pronto<->proxy program<->Escient server. What I mean was that the later case isn't much use to add because just looking at the packets as they go from the pronto to the escient server is pointless because we have the protocol data.

I do see some fun things we can do with a escient simulator. That is a program that simulates the Escient server like for example in a winamp plugin so we can control winamp and list all the songs in the winamp playlists on the pronto remote. BTW. I did check out the SDK for winamp and it does indeed seems like we can get at the playlists for winamp. Just too bad that someone else haven't done this already.

All commands are responded with the same set of 2 packets to acknowledge the commands.
They are simply:
00 00 06 20 00 00 00 00 00 00 00 00 02 00 00 00
00 00 06 40 00 00 00 00 00 00 00 05 01 00 00 00
The 6 is the request number. Actually these two do have some meaning but in our case we can most likely ignore it. The 20 seems to be a 'I got the command and I'm working on it' while the 40 is 'Ok I'm completely done now and I'm ready for more data'.

Has there been any more updates on the rfx protocol?

Mark,

Not on this thread. There was another one where I think user Tenchi was posting.