Power factor in DCE from Gen 2 PDU's

[DCIM_Support]

Is there a way to display the actual power factor measured by a generation 2 PDU in DCE.  The AP8853 (and all other G2 PDU's)  shows PF on the web interface but it does not show up in DCE. 

I also noticed that the value returned via SNMP by the rPDU is always 100 1(denoting 1.00) even though the Power Factor on the web interface may read differently.

Any reason for this?

(CID:97485904)

[DCIM_Support]

Hi Gerry,

For the DCE side of this question, if the PDU does not provide a value other than 1 in it's SNMP output, DCE can not provide anything different for this value. What are you seeing on the web page for the device?

If you can provide the firmware revision being used on the PDU and the version of DCE you're using, I can try to replicate what you're seeing and potentially verify this is or is not an issue with my testing and with engineering.  I have one rPDU2 at my disposal at this time and it's web page shows a power factor of 1 on the web page so I this can not show a difference at this time.

Steve

(CID:97485907)

[DCIM_Support]

Hi, this happens on most G2's as far as I know.  The one shown below is an AP8953 and you can see that the web interface shows Power(W), Apparent Power (VA) and Power Factor .  VA and PF do not get returned to DCE.  I haven't looked to see if VA is returned via SNMP, but out of several that I checked earlier today, 1.0 is returned as PF even though the web interface says differently.  I can't access any rPDU's via raw SNMP from where I am at the moment...

(CID:97485917)

[DCIM_Support]

Hi Gerry,

Looking into it deeper, I did not find an OID in the rPDU2 branch of the mib. In the regular rPDU branch, I did find rPDUIdentDevicePowerFactor. When polling an AP88xx, I got 1. I also noticed it states in the description:

Getting/setting this OID will return/set the
Power Factor in thousanths (1000 is power factor of 1).
This OID does not apply to AP86XX, AP88XX, or AP89XX SKUs.
Valid range is from 0 to 1000.

rPDUIdentDevicePowerVA and rPDUIdentDevicePowerWatts do appear to work properly within the AP88xx I'm testing and there does not appear to be a description stating it is unsupported as there was with the rPDUIdentDevicePowerFactor noted above.

It would appear that the value is simply not available for these units but I am searching for more info from my counterparts in the rPDU side of things but it simply looks like it is unavailable. The NMC inside the PDU is likely doing the math using apparent power and watts to come up with this value if you are indeed seeing a different value on the web interface (that screenshot is the rPDU2 in question yes?). 

Steve

P.S.

Description stated:

Getting/setting this OID .... Sounds like it's something set on the PDU and not measured. If that's the case, It'll never get pulled from the PDU and always be 1. I'll still verify and let you know what I find.

(CID:97485919)

[DCIM_Support]

Hi Gerry,

Can you try polling:

.1.3.6.1.4.1.318.1.1.26.4.3.1.17

It doesn't appear that this rPDU2 OID has the same limitation.

Apparently, on the older AP7XXX Rack PDUs, it is something you can set to help with your power calculations.

I looked through the DDF for the rPDU and I do not find 1.3.6.1.4.1.318.1.1.26.4.3.1.17. It looks like it's something they've left out so I will see if it can be added....stay tuned.

Steve

P.S.

I had an older MIB loaded so I didn't see this one initially either.

(CID:97485923)

[DCIM_Support]

Thanks for the responses. I have looked at this a bit more too. It looks like I suffered a bit of IP address blindness and I managed to use the SNMP browser on a different IP address to the one I was looking at on DCE. One PDU had load on it and the other had none, so I was getting PF = 1 all the time through SNMP as the PDU had no load. It does all make sense to me now though. So the ACTUAL situation is :- .1.3.6.1.4.1.318.1.1.12.1.17 ( rPDUIdentDevicePowerFactor) On a gen 2 rPDU this returns the value of 750 if the PF shown on the web interface is 0.75 – to be expected. On a gen 1 rPDU this returns 1000 all the time. Again to be expected as the Gen 1 does not read PF or VA 1.3.6.1.4.1.318.1.1.26.4.3.1.17 ( rPDU2DeviceStatusPowerFactor) On a gen 2 rPDU this returns the value of 75 if the PF shown on the web interface is 0.75 – to be expected. On a gen 1 rPDU this returns 1 all the time. Again to be expected as the Gen 1 does not read PF or VA So I guess as you said this should be a simple(ish) matter of adding the OID to the DDF for the G2 PDU’s. I noticed also that although the OID rPDU2DeviceStatusApparentPower is available this is also not returned to DCE. Could this be added to the DDF too?

(CID:97485951)

[DCIM_Support]

Hi Gerry, I requested that from multivendorsupport yesterday. I'm waiting on a response. Steve

(CID:97485967)

[DCIM_Support · Accepted solution]

Hi Gary,

Multivendor responded with an updated DDF. If you could, please add this DDF. Your PDUs should update but if not, try removing and re-adding one. Please let me know if it shows the proper info as multivendor will need this before putting it in the system as a default in the future. Without validation, it will not make it in and future updates may overwrite the DDF so if it works now, an overwrite will cause it to stop working....so we need your validation.

Thanks,

Steve

apcpower.xml

(CID:97486494)

[DCIM_Support]

Hi Steve, sorry for the delay in responding - I have tried the DDF and it does now provide both PF and Apparent power for the G2 PDU's.  Thanks for your help

 

(CID:98664514)

[DCIM_Support]

Took a while but I'm glad we got it working for you. Steve

(CID:98664515)

[DCIM_Support]

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.