E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   STATUS_NONE response (http://www.rdmprotocol.org/forums/showthread.php?t=1186)

kenypp January 2nd, 2014 04:32 PM

STATUS_NONE response
 
How should a responder answer a get status request when there are no status warnings or messages pending? The document is not clear on that. I'm currently using the STATUS_NONE type response with the data fields set to 0. That is nine zeros I believe. The test software I'm using shows this as an unknown status response so it must be expecting something else here. If I respond with a warning like "overtemp" , it shows it as expected. Using Enttec RDM controller BTW.

sblair January 2nd, 2014 08:11 PM

Welcome to the forums!

STATUS_NONE is not allowed as a valid Status Type in a response message. This is indicated in Table 10-1 as the NONE type isn't listed as one of the valid return types.

The proper response is to do a standard format GET_COMMAND_RESPONSE for STATUS_MESSAGES with a PDL of 0 and nothing in the Parameter Data (PD) block.

kenypp January 2nd, 2014 09:06 PM

Thanks, that was going to be my second choice to try out although I didn't see it listed anywhere as a suggested response. This responder is a simple light with only a couple of status responses possible. Should I return this empty response for the status clear types and any other status types that the fixture doesn't support?

sblair January 2nd, 2014 10:26 PM

The _CLEARED types are not types that can be requested by the controller. If you look at Table 10-1 the column on the left shows all the possible Status Types that a controller can send to you as a request. The other columns going across are the Status Types allowed to be returned for a given Status Type request.

If you don't support the "_CLEARED" types then all you have to do is just not ever return one as part of a response.

kenypp January 3rd, 2014 11:37 AM

Thanks for explaining table 10-1, that was very helpful.
I had a few quick questions regarding my implementation that I'll add here rather than starting a new thread.
1. Is there a public status warning for "replace bulb"? I didn't see one in the appendix.
2. When responding to get device info, is this still RDM version 1.0? I saw it mentioned in the document even though the document is labeled 1.20.
3. When responding to an unsupported parameter request I am using nack reason unknown. When responding to a set when only get is supported I am using nack reason unsupported parameter. This is how I read it in table A-17. Is this correct?

sblair January 3rd, 2014 01:03 PM

1. There are additional messages posted at: http://tsp.plasa.org/tsp/working_gro...RDMextras.html STS_LOAD_FAILURE is the generally applicable one for a failed lamp. There are some other messages that might be relevant depening on the type of lamp and system involved as we have some that are used for indicating load (wattage) changes and some specific for discharge lamps.

2. Yes, the Protocol Version ID is still 1.0. The E1.20 you see is the ANSI designation for the RDM document. It's not a version number, but the number for the RDM standard as all ANSI standards are identified by a unique number.

3. For responding to an unsupported parameter request, i.e. you get a request for a message PID you don't support you should use NR_UNKNOWN_PID.

If you are responding to a SET request when you only support GET on that message then you should use NR_UNSUPPORTED_COMMAND_CLASS.

Also, I'm not sure where you are located but I would highly suggest attending the upcoming RDM Plugfest in Dallas in a few weeks if you can make it. Details are located here: http://tsp.plasa.org/tsp/news/newsde...php?newsID=459

The event is free and there is access to a lot of RDM testing gear and diagnostics that have been developed to help determine compliance to the standard and what corrections might be needed. Everyone involved with writing the standards are also there so it's a great opportunity to get a lot of free consulting and guidance and implementation testing done.

kenypp January 3rd, 2014 03:05 PM

I'm in the LA area. I don't think I can make it but hopefully there will be lots of stuff posted during and after that will be available. Thanks for the link to additional messages.

ericthegeek January 3rd, 2014 11:05 PM

If you're at all serious about RDM Development, let me reiterate Scott's suggestion to attend the plugfest. The plugfests aren't boring technical presentations. Rather, it's a bunch of engineers sitting around a table with compilers and oscilloscopes to figure out what equipment works well together, and when things don't work why they broke. It's a great chance to play with a wide variety of controllers, responders, splitters, and test equipment, and you'll never find a more knowledgeable group of people about PLASA Control Protocols. We've had developers show up with a basically non-functional product on Friday afternoon, and leave with something that's mostly debugged on Monday.

It's not really something that gets posted on the web afterwards. It's more a case of finding out that your product doesn't work properly when connected to an AAA console through a BBB wireless link.

kenypp January 4th, 2014 10:06 AM

Just to finally clarify the status response question, I'm interpreting table 10-1 as: Always respond to all status requests including status none with at least a standard ack response with no data. Only respond with data if there is a status advisory, warning or error requested and there is something to report. Am I correct? Thanks for all of your help.

ericthegeek January 4th, 2014 09:20 PM

Quote:

Originally Posted by kenypp (Post 2689)
Always respond to all status requests including status none with at least a standard ack response with no data. Only respond with data if there is a status advisory, warning or error requested and there is something to report. Am I correct?

Yes, you are correct.

Also, make sure you handle STATUS_GET_LAST_MESSAGE properly. GET_LAST is used to re-transmit Status Messages (and Queued Messages) when the data gets lost or corrupted in-transit. It's crucial that responders support GET_LAST otherwise messages can be permanently lost.

kenypp January 5th, 2014 10:18 AM

If the last response to a GET_STATUS request was an empty ACK is that what should be returned for a GET_LAST request or do you go back to the last status message that contained data?

ericthegeek January 5th, 2014 01:38 PM

My interpretation is that you should send the Empty Status response.

Another corner case to watch out for if what happens if you receive a STATUS_GET_LAST_MESSAGE before you've received any GET Status Messages requests. Again, in this case you should send an ACK with an empty payload.

kenypp January 5th, 2014 01:57 PM

Thanks Eric

Milton Davis February 7th, 2014 10:25 AM

Further to this, Scott said:

"If you don't support the "_CLEARED" types then all you have to do is just not ever return one as part of a response".

If I receive a request for status type that is one of the _CLEARED variety and I don't support that, what should the response be if I'm not echoing the _CLEARED status type?

Regards,
Milton Davis

ericthegeek February 7th, 2014 10:43 AM

Quote:

Originally Posted by Milton Davis (Post 2738)
If I receive a request for status type that is one of the _CLEARED variety and I don't support that, what should the response be if I'm not echoing the _CLEARED status type?

The controller will never send a request for an _CLEARED Status Type.

The controller will send a GET STATUS_MESSAGES Status Type ERROR. The responder can then return status messages with Status Type ERROR and ERROR_CLEARED.

Request:
GET STATUS_MESSAGES ERROR

Response:
ERROR: Dimmer Room Flood
ERROR: Low Line Voltage
ERROR: Ground Fault Trip
ERROR_CLEARED: Dimmer on fire
ERROR_CLEARED: Dimmer Rack Overtemp

To put it colloquially, the controller asks: "Tell me about your error conditions". The responder then replies "The following 3 error conditions have occurred, and 2 error conditions I reported earlier are no longer present.

The controller will not send:
GET STATUS_MESSAGES ERROR_CLEARED


Edit:
If your responder receives a request for Status Type _CLEARED, you should respond with "NR_DATA_OUT_OF_RANGE".

Milton Davis February 7th, 2014 10:56 AM

Many thanks, Eric. More of the careful interpretation of table 10-1...

Regards,
Milton


All times are GMT -6. The time now is 06:47 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.