Author
Topic: Dusky Sky Controller (Read 17604 times)

I am pleased to announce the birth of a little code !!!! .........concieved in trepidation at 05:50 (first install of 10.04).............birthed by DCEGen at 11:45 today,...........fathered by my "hunt and peck" right index finger

..........midwifery duties most excellently performed by the developers and contributors (forums and wiki).....thank you all.

Ian, what kind of device template did you select to generate the DCE device?What was the cpp file output for the device?I'll have a go at wrapping the existing code into a lib.-Coley.

another update ...I created my own device to keep this going - I'll have to work out with Ian if there is a way of merging what he has done, its category is "AV - Satellite box".Anyway I've added the new device as a child of the MD where the dusky controller is connected.I'm running the device standalone and have populated some of the functions to output the matching commands. The library seems to be emitting the appropriate bytes to control the box

a wee problem - I get nothing through to my device when I press the numeric keypad displayed on the orbiter - where should I start looking to dbg?

@Ian - I had envisaged going down that route before using the existing sky/sky+ template, see earlier in the thread. As the existing template was controlled via IR Thom didn't think it would work as a child of this device.

As it stands the lib called via the DCEdevice handles both usb and serial.Detecting a USB version of the device already works with the existing lmce PnP system. A detection script would need to be added for the serial version, I don't know if it emits any info. This is one of the questions I'll need to ask the dusky guy, Joseph.The other question is whether either dusky device knows what number of ports they have.

@Ian - I had envisaged going down that route before using the existing sky/sky+ template, see earlier in the thread. As the existing template was controlled via IR Thom didn't think it would work as a child of this device.

...................I thought that thom meant not to use ( and therefore alter,) the existing sky plus template, as that would mess around with existing sky users using ir control........I'm suggesting 2 additional templates (duskySky & duskySky+/hd.....and a new ir command group) set up in the wizard as controlled by ir, but using the 4digit codes detailed on dusky's website, plus an additional data box (type int) to indicate which output on the dusky it is connected to.

...........................I assume the dusky knows how many outputs it has, (wether this can be determined i dont know) surely it must, as it returns an error if the wrong command is given in the cli ? ..........but isnt that point mute.....the installer/user filling out the template will know, and, be able to add additional data paramaters in the template, I'd venture that most domestic/normal users won't need anymore than two outputs.

I've had an answer back from Joseph; - The USB controlled dusky controllers will have one or two ports but don't return that info. - The RS232 versions however do return the number of ports at the end of their version string in response to a query, so as Thom says this can easily checked with a script.

@Ian, I wouldn't split the templates into "duskySky & duskySky+/hd". A box type param could be used in the template to determine the appropriate codes to send depending on whether we are connected to a Sky/Sky+/Sky+hd box.

1.......DuskySkyController2.......duskySky ie a sky digibox controlled by Dusky3.......duskySky+/hd ie a Sky+ or Skyhd+ (both at present on same codes)4.......SkyPlus i.e the existing template in the db.

to distinguish the sky boxes controlled by ir (present SkyPlus template) and those controlled by rf/Dusky (which have 2 different codesets )

Nope not at crossed purposes - converging We both agree on not touching existing IR Sky template.Whether we go with a parent as the Dusky controller and each output as a child, or single device with n outputs, I don't know.

but how can we have 2 different codesets in the same template? (for the 2 different types of sat box)

:- agreed, the sat box template(s) need a parameter to show which output on the dusky it's connected to, & then,they can be assigned to different ent. areas/rooms.

Surely it has to be a single box with n outputs,? sitting between the md and the sat box:(the sat box is the av equipment after all,)(the dusky outputs would be better named command channels) or else it's no longer the interface, and becomes the AV device(s) itself..... (and would still need separate codesets to cover the two possible boxes that could be connected to it.)?

And if you wern't confused before ...... !!!!! I know I am

Ian

EDIT any chance you could post your code, so I can try and follow it ?

but how can we have 2 different codesets in the same template? (for the 2 different types of sat box)

If you look at the table on the dusky site http://www.dusky-control.com/sky-control-codes.shtml and look at the sky/sky+ remote control commands you'll see they are all in the format 0x00XX. To convert to a sky+ code 0x0C00 is added and to convert to a skyHD code 0x5C00 is added. This allows the device to send the appropriate command once it knows the box type its connected to. I'm ignoring the sky navigator commands.

I see what you are saying re AV devices vs Interfaces - It can be done either way as you describe - just which is the "right" way?

The code isn't ready for public consumption yet and may end in the bin depending on the design decision of how the DCE device is implemented. If you want to PM me your email address I can send you a tgz of what I've done.

... some more on this;I've parked the initial effort as complete.Now I'm back to the drawing board and have created, as we've teased out here, an interface template "DuskySkyController" and have a child created "skycontrolusb" for now. The device template for the interface has been ticked as implements DCE, while the child doesn't.I've generated the stub devices but don't see the linkage between child and parent - how is this established? i.e. the child spits out debug as orbiter buttons are pressed, but I see nothing from the parent handling the child's commands.