Querying OLA for Command Class (GET/SET) of RDM-defined parameters of devices?

[sdbbs]

Hi all,

Using OLA, I can find the Command Class of RDM Manufacturer-Specific commands / parameters, using the RDM PARAMETER_DESCRIPTION command (see below shell transcript as an example).

What options are there, to do the same for RDM-Defined commands / parameters?


In more detail: the RDM standard (ANSI E1.20) is explicit in "Table A-3: RDM Categories/Parameter ID Defines" in calling its columns "GET Allowed" and "SET Allowed" - I interpret this as: where both GET and SET are allowed as per standard, an RDM device (a lamp) might choose to enable the GET or SET capabilities of an RDM parameter arbitrarily.

For instance, for the LAMP_HOURS RDM-Defined PID, the standard says "used to retrieve the number of lamp hours or to set the counter in the device to a specific starting value.". So, one device/lamp model may choose to enable only GET of LAMP_HOURS, in which case it would always retrieve lamp hours since the device is produced; another lamp model may choose to enable also the SET, to enable the users themselves to change/reset the value of this counter.


So, say I have a lamp device which I know (via SUPPORTED_PARAMETERS RDM parameter PID) supports LAMP_HOURS, which is an *RDM-Defined* parameter PID; how can I query the device via OLA, whether LAMP_HOURS (or any RDM-defined PID) on this device supports only GET, or both GET and SET?

//////

For *manufacturer-specific* RDM PID's, the situation is easier - here is an example:

* Start OLA, go to configuration webpage http://ip-address:9090
* Click Home, take a note of the highest Universe # in use (say, it is 1)
* Click [Add Universe] button, enter next higher Universe # (so, here 2) in both Universe Id and Universe Name fields / and from Available Ports, choose Dummy Device, click Add Universe

Once Universe 2 is set up with Dummy Device and online, we can do an RDM discovery on this universe with OLA from the command line:

```
$ ola_rdm_discover -f --universe 2
7a70:ffffff00
7a70:ffffff01
7a70:ffffff02
7a70:ffffff03
7a70:ffffff04
7a70:ffffff05
```

Let's pick one of these "devices", say the one with RDM UID 7a70:ffffff00, to query for SUPPORTED_PARAMETERS:

```
$ ola_rdm_get -u 2 --uid 7a70:ffffff00 supported_parameters
0x0070 (product_detail_id_list)
0x0080 (device_model_description)
0x0081 (manufacturer_label)
0x0082 (device_label)
0x0090 (factory_defaults)
0x00e0 (dmx_personality)
0x00e1 (dmx_personality_description)
0x0120 (slot_info)
0x0121 (slot_description)
0x0122 (default_slot_value)
0x0200 (sensor_definition)
0x0201 (sensor_value)
0x0202 (record_sensors)
0x0402 (lamp_strikes)
0x0603 (real_time_clock)
0x0700 (list_interfaces)
0x0701 (interface_label)
0x0702 (interface_hardware_address_type1)
0x0705 (ipv4_current_address)
0x070a (ipv4_default_route)
0x070b (dns_ipv4_name_server)
0x070c (dns_hostname)
0x070d (dns_domain_name)
0x8001 (code_version)
```

We can see there is one manufacturer-specific command (RDM PID), which is 0x8001 (code_version); we can query info about it on the 7a70:ffffff00 device, using the PARAMETER_DESCRIPTION RDM command/PID:

```
$ ola_rdm_get -u 2 --uid 7a70:ffffff00 parameter_description 0x8001
PID: 32769
PDL Size: 32
Data Type: ASCII
Command Class: Get
Type: 0
Unit: None
Prefix: None
Min Value: 0
Max Value: 0
Default Value: 0
Description: Code Version
```

And there we go: the "Command Class: Get" in the response tells me that the Manufacturer-Specific RDM PID 0x8001 (code_version) on this device supports only RDM GET, but **not** RDM SET.

So, I would like to obtain the same kind of information about the RDM-Defined PID, say, LAMP_HOURS - or as the dummy device does not define it, we can use LAMP_STRIKES instead, as an example.


The problem is, the PARAMETER_DESCRIPTION RDM command/PID **by definition** (in the RDM standard) is **only** for Manufacturer-Specific RDM commands/PIDs; so if I try PARAMETER_DESCRIPTION with an RDM-Defined command/PID like 0x0402 LAMP_STRIKES, I get:

```
$ ola_rdm_get -u 2 --uid 7a70:ffffff00 parameter_description 0x0402
Request NACKed: Data out of range
```

... nothing (not surprising, in retrospect, given that PARAMETER_DESCRIPTION *by definition* should handle only manufacturer-specific commands, that is RDM PIDs > 0x8000)


So, to summarize: how can I obtain information in OLA command line, whether a given lamp device supports only GET, or only SET, or both, for a given RDM-Defined command/parameter/PID, that the device lists in its SUPPORTED_PARAMETERS?

Thanks in advance for any answers!

[Peter Newman]

Hi,

The short answer is you can't currently, or I guess more accurately you can only find out by trying.

The future looks more promising, there's an updated version of E1.20 that's just gone through another public review cycle (future reviews will show up here https://tsp.esta.org/tsp/documents/public_review_docs.php ). Assuming that version gets standardised, or at least the feature I'm referring to doesn't get removed (which I doubt it) in future there will be an additional PID called SUPPORTED_PARAMETERS_ENHANCED which if the device supports/implements it would let you find out which of get/set it supports for all PIDs it supports.

The longer answer would be as a controller to just try it and see if the fixture lets you. For lamp hours, that will be simple, for some other PID, say POWER_STATE, it could be more complicated, as if it could only support some modes I think, so it could NACK (with an NR_DATA_OUT_OF_RANGE) a request for say POWER_STATE_STANDBY as a setting if it only supported POWER_STATE_FULL_OFF and POWER_STATE_NORMAL, or maybe full off needs a physical switch pressed, but it can do the other states in software. I think the expectation is probably that if the device supports LAMP_STRIKES, you can give the user the option to set (reset) that count and just give them a nice error message if they try to and the fixture rejects it. I'm not sure you can do much better. Its either that or it may be that some of the expensive external data libraries may tell you what a particular device supports so you could make a better UI.

The OLA RDM Tests exercise get/set for each PID to see what's possible, but don't currently really return that in an easy to use way. The Model Collector is less intrusive so doesn't do any sets, but does return more friendly data.

Hopefully that sort of answers your question? If not some more context as to why you want to know would be good; are you making a responder and want to ensure you're doing what you should or making a controller and asking from that perspective?

[sdbbs]

Many thanks for the excellent and in-depth reply, Peter:

>> Hopefully that sort of answers your question?

Of course it does - in fact the opening comment:

>> The short answer is you can't currently, or I guess more accurately you can only find out by trying.

... does it for me; I was in principle wondering if I can "just" query lamps from the controller side, or do I have to "ping" them - and now I know that for the time being, I have to ping.

Although I must say, I am quite excited for SUPPORTED_PARAMETERS_ENHANCED, sounds like something I could put to good use `:)`.

Thanks again for the reply - and all the best until next time!


-----

>
> The short answer is you can't currently, or I guess more accurately you can only find out by trying.
>
> The future looks more promising, there's an updated version of E1.20 that's just gone through another public review cycle (future reviews will show up here https://tsp.esta.org/tsp/documents/public_review_docs.php ). Assuming that version gets standardised, or at least the feature I'm referring to doesn't get removed (which I doubt it) in future there will be an additional PID called SUPPORTED_PARAMETERS_ENHANCED which if the device supports/implements it would let you find out which of get/set it supports for all PIDs it supports.
>
> The longer answer would be as a controller to just try it and see if the fixture lets you. For lamp hours, that will be simple, for some other PID, say POWER_STATE, it could be more complicated, as if it could only support some modes I think, so it could NACK (with an NR_DATA_OUT_OF_RANGE) a request for say POWER_STATE_STANDBY as a setting if it only supported POWER_STATE_FULL_OFF and POWER_STATE_NORMAL, or maybe full off needs a physical switch pressed, but it can do the other states in software. I think the expectation is probably that if the device supports LAMP_STRIKES, you can give the user the option to set (reset) that count and just give them a nice error message if they try to and the fixture rejects it. I'm not sure you can do much better. Its either that or it may be that some of the expensive external data libraries may tell you what a particular device supports so you could make a better UI.
>
> The OLA RDM Tests exercise get/set for each PID to see what's possible, but don't currently really return that in an easy to use way. The Model Collector is less intrusive so doesn't do any sets, but does return more friendly data.
>
> Hopefully that sort of answers your question? If not some more context as to why you want to know would be good; are you making a responder and want to ensure you're doing what you should or making a controller and asking from that perspective?
>
> On Thursday 25 April 2024 at 11:45:50 UTC+1 sd wrote:
>
> Hi all,
>
> Using OLA, I can find the Command Class of RDM Manufacturer-Specific commands / parameters, using the RDM PARAMETER_DESCRIPTION command (see below shell transcript as an example).
>
> What options are there, to do the same for RDM-Defined commands / parameters?
>
>
> In more detail: the RDM standard (ANSI E1.20) is explicit in "Table A-3: RDM Categories/Parameter ID Defines" in calling its columns "GET Allowed" and "SET Allowed" - I interpret this as: where both GET and SET are allowed as per standard, an RDM device (a lamp) might choose to enable the GET or SET capabilities of an RDM parameter arbitrarily.
>
> For instance, for the LAMP_HOURS RDM-Defined PID, the standard says "used to retrieve the number of lamp hours or to set the counter in the device to a specific starting value.". So, one device/lamp model may choose to enable only GET of LAMP_HOURS, in which case it would always retrieve lamp hours since the device is produced; another lamp model may choose to enable also the SET, to enable the users themselves to change/reset the value of this counter.
>
>
> So, say I have a lamp device which I know (via SUPPORTED_PARAMETERS RDM parameter PID) supports LAMP_HOURS, which is an *RDM-Defined* parameter PID; how can I query the device via OLA, whether LAMP_HOURS (or any RDM-defined PID) on this device supports only GET, or both GET and SET?
>
> //////
>
> For *manufacturer-specific* RDM PID's, the situation is easier - here is an example:
>

> * Start OLA, go to configuration webpage http://ip-address:9090 <http://ip-address:9090>

> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
> To unsubscribe from this group, send email to open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en <https://groups.google.com/groups/opt_out?hl=en>
> ---
> You received this message because you are subscribed to the Google Groups "open-lighting" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com <mailto:open-lightin...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/d30b25cb-4533-414f-8d7c-3ba0948faf1bn%40googlegroups.com <https://groups.google.com/d/msgid/open-lighting/d30b25cb-4533-414f-8d7c-3ba0948faf1bn%40googlegroups.com?utm_medium=email&utm_source=footer>.