We don't have a K8000 device, but it's easy to add.
In PlutoAdmin you will go 'Advanced', 'Device Templates'. Choose (ar add) Velleman as the manufacturer, and the category 'Interfaces', 'Specialized', then 'add' to add a "k8000".
You will have to decide if you want to use GSD or C++. C++ is better if there's already a Linux library you want to link to and make system calls. If the K8000 uses a basic serial protocol that you want to implement directly: (ie <stx><0xport_ID><0xcommand><0xparameter><0xchecksum>, etc.), then GSD may be easier. GSD uses embedded ruby with a web-based wizard.
After adding the device template, run DCEGen if you want a C++ program for your device, or go 'wizard', 'devices', 'generic serial devices' if you'll use GSD. See:
http://plutohome.com/support/right.php?section=documents/documentDisplay&docID=51 and
http://plutohome.com/support/index.php?section=document&docID=113Now in PlutoAdmin go to Wizard, Devices, Interfaces. Add the K8000 as an interface. The controlled via is whatever pc you want to run the software on. Go to Wizard, Devices, Security and add some motion sensors, door break, etc. The Controlled Via is the K8000, and the 'Port/Channel' is whatever port you plugged it into in the K8000. You can also add a thermometer on the Wizard, Devices, Climate page, and maybe a light on the Light page.
When defining the device template for the K8000 you can choose what commands it implements and events it fires. Normally this type of device doesn't do any because all commands/events are to/from the child devices. In other words when it's time to turn on the light that's attached to port 5, the "ON" command will go to the 'Light' device which is a child of (or controlled via) the K8000 and has a port/channel of 5. When the motion detector is tripped you will fire a 'sensor tripped' event from the motion detector--not the K8000. The K8000 itself probably does nothing (except maybe on/off???)--it only processes commands on behalf of its children and fires events on their behalf.
This works because the child devices (light switch, motion detector, etc.) do not implement DCE (ie they don't register to receive commands). Therefore DCERouter will walk up the tree to the find the first parent that does (the K8000) and send it all commands destined to its children.
Without knowing this devices my guess is all the code for implementing commands will likely go into the 'ReceivedCommandForChild' function. And there will be probably an event thread to polls it for events and when it gets one fires an event from the appropriate child.
When your device starts up, you will check what are all your child devices, what ports they're on and create whatever structure you want to hold this info. You will also want to check the type or category of teh child device so you know how to handle it. You will treat events from a motion detector differently than events from a thermometer: fire temperature changed events rather than sensor tripped, etc.
