How suitable is DMX/RDM for architectural lighting/home automation applications

[gerrysweeney]

Hi,
I am new to this forum and have a couple of newbe questions, I hope thats ok

1. Where can I get the the E1.20 standard specification document? I have had a look on rdmprotocol.org and while I found some useful overview presentations I could not find the actual specification document, or any reference to it.

2. I have been thinking about developing an architectural digital lighting system for both domestic and commercial applications, this is quite different from stage, show or event lighting as it needs to support local control (aka switches or terminals in each area). I have already settled on signalling based on EIA-485 which is a natural choice for the application. Because I need to handle device discovery and request-response bi-directional data to poll the switched/terminals/sensors I am wondering how well DMX512 and RDM E1.20 are suited to my application, I would rather adopt an open standard than invent something proprietary. Looking through RDM.h it does not appear at first glance there is any specific support/consideration for this type of application. My question therefore is two-fold. Are there any such implementations already? Can anyone with good experience with implementing these protocols give me their initial thoughts/opinion.

Any thoughts/suggestions much appreciated.

Thanks,

Gerry

[sblair]

You're correct. We need to put a clearer link on the site to it. Here's where you can download it from: http://tsp.esta.org/tsp/documents/published_docs.php It will be under E1.20-2010

There are lots of architectural products making use of RDM, particularly color changing fixtures. It is attractive for architectural fixtures, where they need individually addressable fixtures without having to put a UI or DIP Switches that have to be accessed on the fixture itself.

There are messages in Sensors for monitoring contact closures or most any type of sensor you can imagine. You can then take whatever action you want based on those values. Suitability really depends on your application. In cases where you aren't constantly changing intensity values (i.e. a color changing fixture that has a constant color change effect running) and don't need a high refresh rate on the DMX data to maintain a smooth crossfade then you can allocate more time to polling for sensors/switch changes so you can then respond to them with a lower latency.

[gerrysweeney]

Hi Scott,

Thanks for the link, very helpful.

I did see the section in RDM.h for sensors but it did not seem comprehensive enough. For example, consider a well known architectural product made by a company called Lutron (Graffik Eye, Homeworks and other ranges) use a similar scheme using EIA-485 signalling scheme. In this system like others a typical wall switch (terminal) for scene selection can contain anything from a single button to 15 or more buttons, each with their own LED indicator etc, possibly even textual displays. The application requirements are maybe more complex than the odd contact type switch/sensor.

I guess I am just curious to know if there is, or likely to be any work on the standards that would seek to expand to support such architectures.

I will have a read of the standards/specs, thanks again for the link

Gerry

[ericthegeek]

There's no standard set of PIDs for wall-stations within RDM. A "PID" is what RDM calls a command. For example, there are PIDs for setting the DMX address, and for reading sensors.

In the past, there has been some discussion of adding PIDs for "Button Press" and "Button Release" that could be used for wall stations, but it didn't get much traction.

There are a several ways you could implement wall stations using RDM:

Sensors: As Scott suggested, each sensor returns a 16 bit value. You could use this to return 16 individual button presses, or use binary encoding to get many more. Additional sensors could read sliders for dimming control. This could get cumbersome if you have lots of sliders since reading each slider would require one request/response pair.

Status Messages: You can use status messages to report Key Press/Key Release, as well as slider position. The advantage of using status messages is that you can pack multiple statuses into a single response, which could help reduce overhead.

If none of these work for you, you can do whatever you want with Manufacturer-Specific PIDs. Manufacturer-Specific PIDs allow you to define your own commands and then transport them using RDM, while still maintaining compatibility with other equipment using DMX/RDM.

[sblair]

Originally Posted by gerrysweeney

Hi Scott,

I guess I am just curious to know if there is, or likely to be any work on the standards that would seek to expand to support such architectures.


Gerry

We are constantly developing new RDM PIDs (messages) to add different functionality. What you're requesting is something that has been discussed in the past, it is certainly something that we are open to, we just haven't had much interest from someone wanting to really get involved in the standards process and help develop the full suite of messages that would be needed in a broad generic way for architectural systems.

As Eric said, you can always easily create your own manufacturer-specific messages within RDM to do it however you want.