Dusky Sky Controller

[coley]

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.

[coley]

a quick update - I've taken the original code from the dusky website and compiled a small shared lib.
I've taken his "sky-example" file and linked it against my new lib and it seems to work.

@Ian, What template did you base your new DCE device on?

It should now just be a matter of plugging in the exposed functions from the lib into the generated functions in the device cpp file.

-Coley.

[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?

-Coley.

[maybeoneday]

Hi Coley ,

apologies for the abrupt & prolonged abscense,......Who's been a busy boy then ?


I have set up my Dusky as follows


child of GenericPC as core/hybrid

Category #71 Interfaces
manuf  Heenan #1153
#37 ComportOn PC   string
#76 COM Port  parity/bit/stop   string        N81
#78 Baud rate   strinng     B5700
#48 Number of Ports   int     number of outputs on dusky        2
#81 Channel  int          1
#171  Port    int         2


I think more (int)  parameters need to be added  to account for the number of Dusky's on the system and to specify which one the template will refer to

I also think the driver should be able to address both usb & rs232 variants




I set the sky box up as   ............. a child to the dusky.......    sattelite>AV........ir controlled

..........this is what DCEGen used to spit out  the code... which as yet hasn't been compiled and  tested ...I'm trying to work out  what it does  atm       so I've nothing to merge as yet.

So that we  (and anyone else in future)  are  singing off the same hymn sheet  , can I suggest :


          a) we agree  & submit  the required    temlpates  to  "fix" the template numbers & device data  numbers?
                        for e.g  sat box ...manufacturer Sky  ..av/Sat box.....name== "duskySky+/hd"  
                                                             and another  "=duskySky" for the standard digibox
                

          b) open a wiki page (I can do that ) to document  what we're doing, which will also give us a method to swap code and an easy entry point for anyone to jump in , as well as a standard working base  ?

best regards

Ian

    
EDIT: (As my understanding of programming is  VERY limited )  ...I'll get to work on the templates and
the wiki  (edit draft page at   http://wiki.linuxmce.org/index.php/Dusky_Sky_Controller..Driver_Effort  )
  & try to follow what you're doing,  chipping in where I can.

PLEASE can anyone recommend a beginners guide to OOP  and  to C++   ?
  

[coley]

@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.

-Coley.

p.s. I don't know what to recommend regards c++, http://www.cplusplus.com/files/tutorial.pdf maybe as a start,

[maybeoneday]

Hi coley,

I'm a bit confused

@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.

.........as regards serial detection,

quote    "p     0x70   'ping' - makes controller respond 'OK'. Only available in version 0.9.6 onwards"

 ............cplusplus.com was my first port of call , I think it's the OOP part of the business that's confusing me most, I'll keep googling & reading 'till I find something my addled brain will swallow  


Does all this make any sense,

regards,

Ian

[tschak909]

I can help answer questions about C++.

As for the approach with creating a new template, This is the correct action to take, if for no other reason than people may be using the IR template.

If there is a way to scan for Dusky Sky devices, and parse their contents, a radar can be made to accurately detect these devices and send device detected events to the plug and play plugin.

-Thom

[coley]

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.

-Coley.

[maybeoneday]

Hi coley

errm, I think we're at cross purposes, sorry,

what I meant to say was---4 templates in total

1.......DuskySkyController
2.......duskySky              ie a sky digibox controlled by Dusky
3.......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 )


or have I completely misunderstood ?     

regards

Ian

[coley]

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.

A single template can handle the two you refer to here:

2.......duskySky              ie a sky digibox controlled by Dusky
3.......duskySky+/hd        ie a Sky+ or Skyhd+  (both at present on same codes)

If we go the parent child route, having the children in different Entertainment Areas to the parent won't be a problem, I don't know if it is an issue of one device having outputs in different EAs??

-Coley.

[maybeoneday]

ermmm,  sorry if I'm being thick,

 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 ?

  

[coley]

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.

-Coley.

[coley]

In deciding how to add this as an interface can somebody tell me what is the difference between

a.) Device Category - Interfaces #71
b.) Device Category - Interfaces - Specialized #97

as a device category in the device template?

thx,
-Coley.

[coley]

 ... 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.

-Coley.

[tschak909]

Any commands for children need to be implemented in their DCE parent using the ::ReceivedCommandForChild() method.

Basically, the message comes in pMessage, you extract the command and any parameters from it, and do something with it (i.e. use a switch()) ... For examples, look at ZWave, PLCBus, etc.

-Thom