Okay - so it's now supported, but the advertising clearly indicates it's an "out of the box solution," which is not at all the case if one needs to write loads of ProntoScript to get it functional.

Is there any code that exists today to allow this to work with non MCE devices or is code "in the works?"

I am a new ProntoPro user switching over from UEI remotes like the NevoS70 for my customers which integrates a very limted UPnP media browser and configuration utility. It's VERY limited and extremely intermittant - both on compatible devices/servers and other functions.

I am hoping to replace these with the Pronto TSU9600/9800's... can anyone point me in the right direction or is this not the remote to use????


Lee

Another idea: if the above doesn't exist or is too difficult, is there a bridging softare that can be used on a server PC elsewhere - to trick the Pronto into thinking the combination of DLNA server/DMR (e.g., twonky and Dlink DSM520) is a MediaServer?

This might be a better, actually more reliable approach.... anyone?

Pronto now supports UDP sockets. That does not mean it natively supports any of the protocols that ride on UDP. By natively I mean as part of the firmware release.

If you want DLNA or Upnp then you have to write handlers for those protocols juist as with any other OS.

Just remember that above all the Pronto PRO is just a small mobile PC with a nice tool called PEP that can be used to build complex applications. Sometimes I think it unfortunate that Philips sold it as a Remote as opposed to a small handheld touchscreen PC that can be used for many things one of which is emulation of A/V remote control systems.

I completely agree, but it is "what it is..." The TSU series of remotes, while very sophisticated, would be easier on installers and expand the install base if certain functions were added as libraries or modules for installers to further customize. A UPnP/DLNA module library which would allow me to setup media zones, much like the Nevo would be an extremely welcome. They have modules available for Squeezebox, Lutron, Escient, etc., so why not a generic DLNA/UPnP module so that MANY other device groups can be included simultaneously.

Additionally, manufacturers should get incentives to develop modules themselves and we could license these modules from them for us (i.e., Denon, etc.). But, I digress....

I just want the ability to integrate 2-way control with my customer's media devices without having to write a complete Java application. Escient and the other included libraries are for some very pricey devices, not all customers can afford them.

I am writing this right now - but there is one major issue. The UPnP protocol needs the IP address of the remote to support eventing and this is not available to ProntoScript. If you can live with a static IP on the host (I can't) then I have most of it written but need to test it in January.

I can definitely tolerate static IPs, let me know if you need help testing.

Lee

I am pretty sure the new Pronto firmware supports

var IP=System.getIPAddress() // should return the IP address of this Pronto

Although not documented in the most recent version of the Developer's Guide, this works as expected.

Paul

hello buddy

How you doing? How's this coming along?

Cheers

Have been distracted by a load of issues with losing data on serial ports that were exacerbated with the new firmware but my Roku Soundbridge controller is in reasonable shape. That sits on top of a UPnP/SSDP layer and that seems to work fine (I haven't really beaten up the UPnP event model as that isn't really used for the Soundbridge and I am using RCP for most of the control surface). Happy to share the SSDP piece if that is a help....

Mark

How's Roku control coming along?

I would love it if those changes for serial.match() on 7.2.22 could be backed out.

Lyndel: Are you working on Roku control? What's the easiest way to send/receive across IP to do string compares (I.e., send x, get y response and perform z function)? I never got this sophisticated in my programming... Maybe I will give it a shot if there's a way to send/receive over IP that is as relatively simple as serial....