DMX

From Automated Home

1 Info
2 DMX USB
3 DMX Moodlights
4 DMX Gallery
5 Shops

[edit] Info

DMX is usually used 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.

However there are more practical uses for it too.

[edit] DMX USB

DMX USB

To be able to control the panels by computer, I am using the Enttec DMX usb pro controller (see 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).

[edit] DMX Moodlights

DMX Panel

These moodlight panels are controlled using the DMX protocol. 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).

The following is a project of lennart, the examples below in the gallery are from lennart too.

Each square has its own RGB values, so it is certainly possible to dim the panel. Just supply very low values for R, G, and/or B, depending on the colour that you'd like; it's all based on colour mixing. For example: if I set all squares to hex colourcode 330000 (low red, no green, no blue), it will show a very dim red and if I set all squares to hex colourcode 333333 (low red, low green and low blue), it will be a very dim white (kind of pale). At "full power" they are quite bright (15 Watt led power per panel), although it remains ambient mood lighting and can't replace primary lighting.

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