EcoStruxure IT forum
A support forum for Data Center Operation, Data Center Expert, and EcoStruxure IT product users to share knowledge on installation, configuration, and general product use.
Posted: 2020-07-05 08:32 PM
This question was originally posted on DCIM Support by Brian Ellwood on 2019-07-09
When I make the following call:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:isx="http://www.apc.com/stdws/xsd/ISXCentralSensors-v2" xmlns:isx1="http://www.apc.com/stdws/wsdl/ISXCentralSensors-v2"> <soapenv:Header/> <soapenv:Body> <isx:getSensorsForDeviceRequest> <isx:ISXCElementID>B16b483_nbSNMPEnc2F029397</isx:ISXCElementID> </isx:getSensorsForDeviceRequest> </soapenv:Body> </soapenv:Envelope>...part of the response includes:
<ns2:ISXCSensor xmlns:ns2="http://www.apc.com/stdws/xsd/ISXCentral/2009/10"> <ns2:ISXCNamedElement> <ns2:ISXCElement> <ns2:ISXCElementType>SENSOR</ns2:ISXCElementType> <ns2:id>B16b483_nbSNMPEnc2F029397_OUTPUT_POWER_TOTAL_2</ns2:id> </ns2:ISXCElement> <ns2:name>Device 2 (R29-PDU-B) - Total Real Power</ns2:name> </ns2:ISXCNamedElement> <ns2:index></ns2:index> <ns2:parentID>B16b483_nbSNMPEnc2F029397</ns2:parentID> <ns2:ISXCSensorType>UNKNOWN</ns2:ISXCSensorType> <ns2:ISXCSensorState>NONE</ns2:ISXCSensorState> <ns2:supplemental xsi:nil="true" /> </ns2:ISXCSensor> <ns2:ISXCSensor xmlns:ns2="http://www.apc.com/stdws/xsd/ISXCentral/2009/10"> <ns2:ISXCNamedElement> <ns2:ISXCElement> <ns2:ISXCElementType>SENSOR</ns2:ISXCElementType> <ns2:id>B16b483_nbSNMPEnc2F029397_OUTPUT_POWER_TOTAL_1</ns2:id> </ns2:ISXCElement> <ns2:name>Device 1 (R29-PDU-A) - Total Real Power</ns2:name> </ns2:ISXCNamedElement> <ns2:index></ns2:index> <ns2:parentID>B16b483_nbSNMPEnc2F029397</ns2:parentID> <ns2:ISXCSensorType>OUTPUT_POWER_TOTAL_WATTS</ns2:ISXCSensorType> <ns2:ISXCSensorState>NONE</ns2:ISXCSensorState> <ns2:supplemental xsi:nil="true" /> </ns2:ISXCSensor>Please note that the sensor type for Device 2 (a linked PDU) is “unknown” when it should be “OUTPUT_POWER_TOTAL_WATTS” as well. This is a problem, because if I ask for that sensor type specifically:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:isx="http://www.apc.com/stdws/xsd/ISXCentralSensors-v2" xmlns:isx1="http://www.apc.com/stdws/wsdl/ISXCentralSensors-v2"> <soapenv:Header/> <soapenv:Body> <isx:getSensorsForDeviceRequest> <isx:ISXCElementID>B16b483_nbSNMPEnc2F029397</isx:ISXCElementID> <isx:ISXCSensorType>OUTPUT_POWER_TOTAL_WATTS</isx:ISXCSensorType> </isx:getSensorsForDeviceRequest> </soapenv:Body> </soapenv:Envelope>...I only get one of the sensors back:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body xmlns:ns1="http://www.apc.com/stdws/xsd/ISXCentralSensors-v2"> <ns1:getSensorsForDeviceResponse> <ns1:ArrayOfISXCSensor> <ns2:ISXCSensor xmlns:ns2="http://www.apc.com/stdws/xsd/ISXCentral/2009/10"> <ns2:ISXCNamedElement> <ns2:ISXCElement> <ns2:ISXCElementType>SENSOR</ns2:ISXCElementType> <ns2:id>B16b483_nbSNMPEnc2F029397_OUTPUT_POWER_TOTAL_1</ns2:id> </ns2:ISXCElement> <ns2:name>Device 1 (R29-PDU-A) - Total Real Power</ns2:name> </ns2:ISXCNamedElement> <ns2:index></ns2:index> <ns2:parentID>B16b483_nbSNMPEnc2F029397</ns2:parentID> <ns2:ISXCSensorType>OUTPUT_POWER_TOTAL_WATTS</ns2:ISXCSensorType> <ns2:ISXCSensorState>NONE</ns2:ISXCSensorState> <ns2:supplemental xsi:nil="true" /> </ns2:ISXCSensor> </ns1:ArrayOfISXCSensor> </ns1:getSensorsForDeviceResponse> </soap:Body> </soap:Envelope>It looks like any linked PDU's all have an "unknown" value for the sensor type when involving "OUTPUT_POWER".
The support desk told me to post this here for proper eyes from the API dev team.
We are running the latest 7.7.x of DCE VM.
(CID:146671216)
Posted: 2020-07-05 08:32 PM
This answer was originally posted on DCIM Support by Brian Ellwood on 2019-09-26
DCE support issued a supplemental sensor context that has thus far resolved this.
I'm told a forthcoming version of DCE will include the fix for this.
(CID:149292493)
Posted: 2020-07-05 08:32 PM
This answer was originally posted on DCIM Support by Jake Hiltz on 2019-07-12
Hi Brian,
Most likely the DDF within DCE needs to be updated, or a context file needs to be added. We can help with that. Would you mind creating a device support request? To do that, please go to this page: https://ddf.ecostruxureit.com/, then it will make you search for something before you can see the request button. You can just link to this community post instead of re-explaining the entire thing. Thank you for the detailed explanation. In addition, we will just need to know which DDF you are using, and perhaps have you send it to us if we don't have a copy.
Thanks,
Jake
(CID:147194920)
Posted: 2020-07-05 08:32 PM
This comment was originally posted on DCIM Support by Brian Ellwood on 2019-07-12
Jake,
How do I determine from within DCE what DDF(s) are being used for the linked RackPDUs?
(CID:147194967)
Posted: 2020-07-05 08:32 PM
This comment was originally posted on DCIM Support by Brian Ellwood on 2019-07-12
I've provided screenshots of the list of DDF's we have installed on the request. Please let me know if you need further information.
(CID:147194968)
Posted: 2020-07-05 08:32 PM
This answer was originally posted on DCIM Support by Jake Hiltz on 2019-08-13
Hi Brian,
It turns out that because this is a linked RPDU, the API can't differentiate between the multiple devices. It appears as a single device to DCE. That is why the second device has an unknown sensor type.
(CID:147784027)
Posted: 2020-07-05 08:32 PM
This answer was originally posted on DCIM Support by Brian Ellwood on 2019-09-26
DCE support issued a supplemental sensor context that has thus far resolved this.
I'm told a forthcoming version of DCE will include the fix for this.
(CID:149292493)
Posted: 2020-07-05 08:32 PM
This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.
Create your free account or log in to subscribe to the forum - and gain access to more than 10,000+ support articles along with insights from experts and peers.