Usage of PARAMETER_DESCRIPTION for manufacturer-specific PIDs - E1.20 RDM (Remote Device Management) Protocol Forums

sblair · January 7th, 2011

As has been said, the current PARAMETER_DESCRIPTION PID was only intended to handle a single data value and even at that it is of limited use.

A reminder that you only need to use the PARAMETER_DESCRIPTION PID if you're trying to publicly expose a manufacturer-specific PID to others. If you are just creating it for your own use, then you don't even need to bother with trying to describe it as you'll already know the data structure for it.

If you're trying to make it publicly accessible to other controllers, then I'd try rethinking it and breaking it down into multiple PIDs that each handle a single data value.

Not the best solution, but those are the current workarounds.

nomis52 · January 15th, 2011

As a couple of you know I've come up with a different approach to this problem - the online PID definition index: http://rdm.openlighting.org/

This provides a structured way of describing a PID's format in a much richer way than the PARAMETER DESCRIPTION PID supports. Think of it as DDL for RDM.

The big advantage here is that the data format isn't tied to the RDM specification.

I'm happy to export the data in other formats (XML, JSON etc.) for other people to use in their controllers. Other programs can check the last update time by hitting http://rdm.openlighting.org/update_time

See you all in Dallas.

Simon

January 7th, 2011	#1
sblair Administrator Join Date: Feb 2006 Posts: 441	As has been said, the current PARAMETER_DESCRIPTION PID was only intended to handle a single data value and even at that it is of limited use. A reminder that you only need to use the PARAMETER_DESCRIPTION PID if you're trying to publicly expose a manufacturer-specific PID to others. If you are just creating it for your own use, then you don't even need to bother with trying to describe it as you'll already know the data structure for it. If you're trying to make it publicly accessible to other controllers, then I'd try rethinking it and breaking it down into multiple PIDs that each handle a single data value. Not the best solution, but those are the current workarounds. __________________ Scott M. Blair RDM Protocol Forums Admin

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Manufacturer Specific Pids	berntd	RDM General Implementation Discussion	4	November 29th, 2009 02:50 PM
PARAMETER_DESCRIPTION data type semantics	tim_ecue	RDM Interpretation Questions	4	October 14th, 2009 10:47 AM
PDL size and manufacturer specific parameter ID's	jamie	RDM General Implementation Discussion	5	July 13th, 2009 12:31 AM

January 15th, 2011	#2
nomis52 Task Group Member Join Date: May 2010 Location: San Franciscio Posts: 57	As a couple of you know I've come up with a different approach to this problem - the online PID definition index: http://rdm.openlighting.org/ This provides a structured way of describing a PID's format in a much richer way than the PARAMETER DESCRIPTION PID supports. Think of it as DDL for RDM. The big advantage here is that the data format isn't tied to the RDM specification. I'm happy to export the data in other formats (XML, JSON etc.) for other people to use in their controllers. Other programs can check the last update time by hitting http://rdm.openlighting.org/update_time See you all in Dallas. Simon