For your entertainment, I just wanted to let you know that I'm making some progress on my latest home automation project: DMX controlled moodlight panels.
The setup consists of 4 Traxon moodlight panels (classic DMX version) that are on the wall of our master bedroom (see http://www.traxontechnologies.com/products/view/17 for more product details).
These moodlight panels are controlled using the DMX protocol, which has its roots in the field of professional lighting (stage lighting for theatres, concerts, etc.). It's a protocol you don't see that often in the context of home automation, which is a pity as it offers a nice way to control more modern lighting equipment, such as RGB led fixtures.
The DMX protocol is quite simple: every device occupies one or more channels in the range 0 to 511 (the so called DMX universe). Typically one channel for red, one for green and one for blue are used in case of an RGB lighting fixture but scanners exist that use channels for x-y-z axis positions as well. Usually the start channel (i.e. the address) is configurable for each DMX device. Devices are daisy chained and controlling the devices basically consists of sending frames of 512 bytes (with of course 8 bit value resolution) and a preceding start byte. It's a very basic one-way serial protocol (RS-485 based), without acknowledgments, error checking or error correction.
DMX uses it's own cabling and connectors (XLR, officially 5 pin), but the panels that I used have RJ45 connectors and can be connected using standard UTP cabling. Although the cabling is UTP, the protocol is still DMX, so connecting these cables to the home network will not work, although a DMX over TCP/IP protocol does exist nowadays, but equipment in that category is a lot more expensive.
Each moodlight panel consists of 4 subpanels that can be individually controlled. Each subpanel uses three channels (R, G and B). Each panel therefore needs 12 DMX channels. The whole setup thus takes up 48 DMX channels (1 through 48).
To be able to control the panels by computer, I am using the Enttec DMX usb pro controller (see http://www.enttec.com/index.php?main_me ... =dmxusbpro for more product details).
It behaves as a serial device and can thus be easily accessed through a virtual com port. Enttec uses its own (documented!) protocol between computer and usb DMX controller, but for sending DMX frames to the devices, it's very similar to the DMX protocol itself (just some differences is control bytes). The controller is "intelligent" in the sense that it has its own frame buffer and takes care of timing issues itself, as opposed to the less expensive open DMX usb controller (also produced by Enttec; the design of that device has been published under the GPL). The Enttec device works on both Linux and Win32 platforms (I'm using it on Win32).
To connect the panels to the controller I had to run a dedicated UTP cable from the panels to the computer and use the RJ45 to XLR cable that was provided with the panels, as well as an RJ45 coupler.
To control the panels, I wrote some software. For flexibility, I'm using a Perl program that continuously monitors (once per second) a MySQL database table for changes. In this table, I have stored a record that basically tells the Perl program whether the panels should be on or off, what lighting program it should run (single fixed colour, random colours, colour chases, fading, figures, etc., I currently have created about fifteen different ones) and what user parameters are provided (colours, timing, etc.). The Perl program translates the selected lighting program, together with the parameters, into one or more frames (taking timing of fades into account) that are sent out to the Enttec controller and relayed to the panels. The frames are repeated if required, such as in the case of colour chases and repeated fading. The power supplies of the panels are behind a Xanura SAX1 module, so the panels can also be really switched off if no lighting program is running.
The Perl program keeps on checking for changes in the MySQL record while a lighting program runs, so lighting programs can be changed or terminated almost instantly (there's no need "to sit them out"). The wish for this feature, together with the wish to control the panels through a webbased interface and the fact that potentially long running lighting programs and time limited - short running - webbased scripts don't match very well, made me opt for the database "passthrough" solution. Basically, the record in the MySQL tabel is a token that signals the Perl program what it should do and decouples the actual running of a lighting program from controlling it. The token could of course also be file based, but I'm using a home automation MySQL database anyway and it interfaces quite well with other systems.
The MySQL record (i.e. the token) can of course be updated from numerous sources to control the lighting: Homeseer (using a script), other home automation software, or any homebrew software. Currently, I'm using a basic homebrew PHP script with a form to select the lighting program and parameters, which updates the MySQL record accordingly. I'm planning on building a PHP based home automation site that is basically a front-end to Homeseer and this would integrate very well into this front-end. In case you didn't know: it's possible to control Homeseer through PHP using a COM object; one can get status information on all devices and set their properties. This is a comfortable solution if you want to have full PHP-based control over the front-end of your home automation system, but, just like me, don't want to spend too much time (yet) on writing com port drivers for devices such as RFXcom receivers/transmitters, Xanura CTX35 interface, etc. yourself if these are already available in a convenient package such as Homeseer. But that's a whole different topic
.Here are some pictures of the result, which I hope you enjoy:
Now that the basic setup seems to work, I can concentrate on writing some other interesting lighting programs for the panels. Any ideas?
Best wishes,
Lennart
