Parameter Description for PIDs declared by SubDevice
 

There appears to be a hole in the E1.20 standard in that there is no logical way of getting the Paramater Description of a Manufacturer Specific PID that might appear in a SubDevice's list of supported PIDS.

It appears that we unnecessarily restrict the GET:PARAMETER DESCRIPTION PID to be sent only to Root Devices.

Including my thoughts here for the discussion (Peter and I discussed this earlier):

Manufacturer specific PIDs are supposed to be the same for all devices from the same manufacturer, Thus, as long as you can get the PARAMETER_DESCRIPTION for the Sub-device's PID from somewhere, it will give you the information you need.

Thus, you could send a GET PARAMETER_DESCRIPTION to the root to get the description for a PID that is only supported in the Sub-Device(s).

Just because the root gives you a description for a manufacturer specific PID doesn't automatically mean that the root supports that PID.

While reading through the E1.20 doc, the same question applies to STATUS_ID_DESCRIPTION. It can only be sent to the rood, so you'd have to ask the root for the description of a status code that was returned from a sub-device. This may be less of a concern though, since STATUS_MESSAGES should only be sent to the root device.

Hello,
On page 55 of the standard in reference to SUPPORTED PARAMETERS PID it is written: "Manufacturer specific PIDs may or may not be included in the response". If I have implemented a MANUFACTURER SPECIFIC PID in my device, I need to list it otherwise the controller has no other way of knowing about its existence. Am I right? And what about the STATUS_ID_DESCRIPTION of a MANUFACTURER SPECIFIC message? How does the controller know in advance the implemented STATUS ID to be able to request its description?
Does it request it a posteriori? Thanks

Yes, if you want controllers to be able to use a Manufacturer-Specific PID, then you should include it in the list of supported parameters.

However, sometimes there are non-public PIDs that manufacturers don't want to be visible. For example, there might be a calibration PID that is only intended for factory use.

Also, there might be a PID that is only intended for use when someone is on the phone with your support team. Support might tell the user to send a specific PID and then read the response to help troubleshoot a problem.

For this reason, many controllers allow you to send a specific HEX PID, even if that PID is not in the list of supported parameters.

A controller should not need to know every supported Status ID in advance, it can request the STATUS_ID_DESCRIPTION when it first receives that ID.

For example, if a responder reports status ID 0x9345, and the responder doesn't know what 0x9345 means, then it can request the status ID description at that time