librenms/tests/data/dell-rpdu.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2395 lines
105 KiB
JSON
Raw Normal View History

{
"os": {
"discovery": {
"devices": [
{
"sysName": "<private>",
"sysObjectID": ".1.3.6.1.4.1.674.10903.200.3.1",
"sysDescr": "DELL Web/SNMP Management Card (MB:V1.0f PF:v5.1.4 PN:dell_hw05_aos_514.bin AF1:v5.1.2 AN1:dell_hw05_rpdud_512.bin MN:DELL6606 HR:HW01 SN: IN1A234B5678912CD345E67 MD:09/19/2013)",
"sysContact": "<private>",
"version": "v5.1.2",
"hardware": "DELL6606 HW01",
"features": null,
"os": "dell-rpdu",
"type": "power",
"serial": "IN1A234B5678912CD345E67",
"icon": "dell.svg",
"location": "<private>"
}
]
},
"poller": "matches discovery"
},
"ports": {
"discovery": {
"ports": [
{
"port_descr_type": null,
"port_descr_descr": null,
"port_descr_circuit": null,
"port_descr_speed": null,
"port_descr_notes": null,
"ifDescr": "LOOPBACK",
"ifName": "LOOPBACK",
"portName": null,
"ifIndex": 1,
"ifSpeed": null,
"ifSpeed_prev": null,
"ifConnectorPresent": null,
"ifPromiscuousMode": null,
"ifOperStatus": "up",
"ifOperStatus_prev": null,
"ifAdminStatus": null,
"ifAdminStatus_prev": null,
"ifDuplex": null,
"ifMtu": null,
"ifType": "softwareLoopback",
"ifAlias": "LOOPBACK",
"ifPhysAddress": null,
"ifHardType": null,
"ifLastChange": 0,
"ifVlan": "",
"ifTrunk": null,
"counter_in": null,
"counter_out": null,
"ignore": 0,
"disabled": 0,
"detailed": 0,
"deleted": 0,
"pagpOperationMode": null,
"pagpPortState": null,
"pagpPartnerDeviceId": null,
"pagpPartnerLearnMethod": null,
"pagpPartnerIfIndex": null,
"pagpPartnerGroupIfIndex": null,
"pagpPartnerDeviceName": null,
"pagpEthcOperationMode": null,
"pagpDeviceId": null,
"pagpGroupIfIndex": null,
"ifInUcastPkts": null,
"ifInUcastPkts_prev": null,
"ifInUcastPkts_delta": null,
"ifInUcastPkts_rate": null,
"ifOutUcastPkts": null,
"ifOutUcastPkts_prev": null,
"ifOutUcastPkts_delta": null,
"ifOutUcastPkts_rate": null,
"ifInErrors": null,
"ifInErrors_prev": null,
"ifInErrors_delta": null,
"ifInErrors_rate": null,
"ifOutErrors": null,
"ifOutErrors_prev": null,
"ifOutErrors_delta": null,
"ifOutErrors_rate": null,
"ifInOctets": null,
"ifInOctets_prev": null,
"ifInOctets_delta": null,
"ifInOctets_rate": null,
"ifOutOctets": null,
"ifOutOctets_prev": null,
"ifOutOctets_delta": null,
"ifOutOctets_rate": null,
"poll_prev": null,
"ifInNUcastPkts": null,
"ifInNUcastPkts_prev": null,
"ifInNUcastPkts_delta": null,
"ifInNUcastPkts_rate": null,
"ifOutNUcastPkts": null,
"ifOutNUcastPkts_prev": null,
"ifOutNUcastPkts_delta": null,
"ifOutNUcastPkts_rate": null,
"ifInDiscards": null,
"ifInDiscards_prev": null,
"ifInDiscards_delta": null,
"ifInDiscards_rate": null,
"ifOutDiscards": null,
"ifOutDiscards_prev": null,
"ifOutDiscards_delta": null,
"ifOutDiscards_rate": null,
"ifInUnknownProtos": null,
"ifInUnknownProtos_prev": null,
"ifInUnknownProtos_delta": null,
"ifInUnknownProtos_rate": null,
"ifInBroadcastPkts": null,
"ifInBroadcastPkts_prev": null,
"ifInBroadcastPkts_delta": null,
"ifInBroadcastPkts_rate": null,
"ifOutBroadcastPkts": null,
"ifOutBroadcastPkts_prev": null,
"ifOutBroadcastPkts_delta": null,
"ifOutBroadcastPkts_rate": null,
"ifInMulticastPkts": null,
"ifInMulticastPkts_prev": null,
"ifInMulticastPkts_delta": null,
"ifInMulticastPkts_rate": null,
"ifOutMulticastPkts": null,
"ifOutMulticastPkts_prev": null,
"ifOutMulticastPkts_delta": null,
"ifOutMulticastPkts_rate": null
},
{
"port_descr_type": null,
"port_descr_descr": null,
"port_descr_circuit": null,
"port_descr_speed": null,
"port_descr_notes": null,
"ifDescr": "lance",
"ifName": "lance",
"portName": null,
"ifIndex": 2,
"ifSpeed": null,
"ifSpeed_prev": null,
"ifConnectorPresent": null,
"ifPromiscuousMode": null,
"ifOperStatus": "up",
"ifOperStatus_prev": null,
"ifAdminStatus": null,
"ifAdminStatus_prev": null,
"ifDuplex": null,
"ifMtu": null,
"ifType": "ethernetCsmacd",
"ifAlias": "lance",
"ifPhysAddress": null,
"ifHardType": null,
"ifLastChange": 0,
"ifVlan": "",
"ifTrunk": null,
"counter_in": null,
"counter_out": null,
"ignore": 0,
"disabled": 0,
"detailed": 0,
"deleted": 0,
"pagpOperationMode": null,
"pagpPortState": null,
"pagpPartnerDeviceId": null,
"pagpPartnerLearnMethod": null,
"pagpPartnerIfIndex": null,
"pagpPartnerGroupIfIndex": null,
"pagpPartnerDeviceName": null,
"pagpEthcOperationMode": null,
"pagpDeviceId": null,
"pagpGroupIfIndex": null,
"ifInUcastPkts": null,
"ifInUcastPkts_prev": null,
"ifInUcastPkts_delta": null,
"ifInUcastPkts_rate": null,
"ifOutUcastPkts": null,
"ifOutUcastPkts_prev": null,
"ifOutUcastPkts_delta": null,
"ifOutUcastPkts_rate": null,
"ifInErrors": null,
"ifInErrors_prev": null,
"ifInErrors_delta": null,
"ifInErrors_rate": null,
"ifOutErrors": null,
"ifOutErrors_prev": null,
"ifOutErrors_delta": null,
"ifOutErrors_rate": null,
"ifInOctets": null,
"ifInOctets_prev": null,
"ifInOctets_delta": null,
"ifInOctets_rate": null,
"ifOutOctets": null,
"ifOutOctets_prev": null,
"ifOutOctets_delta": null,
"ifOutOctets_rate": null,
"poll_prev": null,
"ifInNUcastPkts": null,
"ifInNUcastPkts_prev": null,
"ifInNUcastPkts_delta": null,
"ifInNUcastPkts_rate": null,
"ifOutNUcastPkts": null,
"ifOutNUcastPkts_prev": null,
"ifOutNUcastPkts_delta": null,
"ifOutNUcastPkts_rate": null,
"ifInDiscards": null,
"ifInDiscards_prev": null,
"ifInDiscards_delta": null,
"ifInDiscards_rate": null,
"ifOutDiscards": null,
"ifOutDiscards_prev": null,
"ifOutDiscards_delta": null,
"ifOutDiscards_rate": null,
"ifInUnknownProtos": null,
"ifInUnknownProtos_prev": null,
"ifInUnknownProtos_delta": null,
"ifInUnknownProtos_rate": null,
"ifInBroadcastPkts": null,
"ifInBroadcastPkts_prev": null,
"ifInBroadcastPkts_delta": null,
"ifInBroadcastPkts_rate": null,
"ifOutBroadcastPkts": null,
"ifOutBroadcastPkts_prev": null,
"ifOutBroadcastPkts_delta": null,
"ifOutBroadcastPkts_rate": null,
"ifInMulticastPkts": null,
"ifInMulticastPkts_prev": null,
"ifInMulticastPkts_delta": null,
"ifInMulticastPkts_rate": null,
"ifOutMulticastPkts": null,
"ifOutMulticastPkts_prev": null,
"ifOutMulticastPkts_delta": null,
"ifOutMulticastPkts_rate": null
}
]
},
"poller": {
"ports": [
{
"port_descr_type": null,
"port_descr_descr": null,
"port_descr_circuit": null,
"port_descr_speed": null,
"port_descr_notes": null,
"ifDescr": "LOOPBACK",
"ifName": "LOOPBACK",
"portName": null,
"ifIndex": 1,
"ifSpeed": 0,
"ifSpeed_prev": null,
"ifConnectorPresent": null,
"ifPromiscuousMode": null,
"ifOperStatus": "up",
"ifOperStatus_prev": "up",
"ifAdminStatus": "up",
"ifAdminStatus_prev": null,
"ifDuplex": null,
"ifMtu": 1500,
"ifType": "softwareLoopback",
"ifAlias": "LOOPBACK",
"ifPhysAddress": null,
"ifHardType": null,
"ifLastChange": 0,
"ifVlan": "",
"ifTrunk": null,
"counter_in": null,
"counter_out": null,
"ignore": 0,
"disabled": 0,
"detailed": 0,
"deleted": 0,
"pagpOperationMode": null,
"pagpPortState": null,
"pagpPartnerDeviceId": null,
"pagpPartnerLearnMethod": null,
"pagpPartnerIfIndex": null,
"pagpPartnerGroupIfIndex": null,
"pagpPartnerDeviceName": null,
"pagpEthcOperationMode": null,
"pagpDeviceId": null,
"pagpGroupIfIndex": null,
"ifInUcastPkts": 0,
"ifInUcastPkts_prev": 0,
"ifInUcastPkts_delta": null,
"ifInUcastPkts_rate": null,
"ifOutUcastPkts": 0,
"ifOutUcastPkts_prev": 0,
"ifOutUcastPkts_delta": null,
"ifOutUcastPkts_rate": null,
"ifInErrors": 0,
"ifInErrors_prev": 0,
"ifInErrors_delta": null,
"ifInErrors_rate": null,
"ifOutErrors": 0,
"ifOutErrors_prev": 0,
"ifOutErrors_delta": null,
"ifOutErrors_rate": null,
"ifInOctets": 0,
"ifInOctets_prev": 0,
"ifInOctets_delta": null,
"ifInOctets_rate": null,
"ifOutOctets": 0,
"ifOutOctets_prev": 0,
"ifOutOctets_delta": null,
"ifOutOctets_rate": null,
"poll_prev": null,
"ifInNUcastPkts": 0,
"ifInNUcastPkts_prev": 0,
"ifInNUcastPkts_delta": null,
"ifInNUcastPkts_rate": null,
"ifOutNUcastPkts": 0,
"ifOutNUcastPkts_prev": 0,
"ifOutNUcastPkts_delta": null,
"ifOutNUcastPkts_rate": null,
"ifInDiscards": 0,
"ifInDiscards_prev": 0,
"ifInDiscards_delta": null,
"ifInDiscards_rate": null,
"ifOutDiscards": 0,
"ifOutDiscards_prev": 0,
"ifOutDiscards_delta": null,
"ifOutDiscards_rate": null,
"ifInUnknownProtos": 0,
"ifInUnknownProtos_prev": 0,
"ifInUnknownProtos_delta": null,
"ifInUnknownProtos_rate": null,
"ifInBroadcastPkts": 0,
"ifInBroadcastPkts_prev": 0,
"ifInBroadcastPkts_delta": null,
"ifInBroadcastPkts_rate": null,
"ifOutBroadcastPkts": 0,
"ifOutBroadcastPkts_prev": 0,
"ifOutBroadcastPkts_delta": null,
"ifOutBroadcastPkts_rate": null,
"ifInMulticastPkts": 0,
"ifInMulticastPkts_prev": 0,
"ifInMulticastPkts_delta": null,
"ifInMulticastPkts_rate": null,
"ifOutMulticastPkts": 0,
"ifOutMulticastPkts_prev": 0,
"ifOutMulticastPkts_delta": null,
"ifOutMulticastPkts_rate": null
},
{
"port_descr_type": null,
"port_descr_descr": null,
"port_descr_circuit": null,
"port_descr_speed": null,
"port_descr_notes": null,
"ifDescr": "lance",
"ifName": "lance",
"portName": null,
"ifIndex": 2,
"ifSpeed": 10000000,
"ifSpeed_prev": null,
"ifConnectorPresent": null,
"ifPromiscuousMode": null,
"ifOperStatus": "up",
"ifOperStatus_prev": "up",
"ifAdminStatus": "up",
"ifAdminStatus_prev": null,
"ifDuplex": null,
"ifMtu": 1500,
"ifType": "ethernetCsmacd",
"ifAlias": "lance",
"ifPhysAddress": "0023aee300de",
"ifHardType": null,
"ifLastChange": 10,
"ifVlan": "",
"ifTrunk": null,
"counter_in": null,
"counter_out": null,
"ignore": 0,
"disabled": 0,
"detailed": 0,
"deleted": 0,
"pagpOperationMode": null,
"pagpPortState": null,
"pagpPartnerDeviceId": null,
"pagpPartnerLearnMethod": null,
"pagpPartnerIfIndex": null,
"pagpPartnerGroupIfIndex": null,
"pagpPartnerDeviceName": null,
"pagpEthcOperationMode": null,
"pagpDeviceId": null,
"pagpGroupIfIndex": null,
"ifInUcastPkts": 11179,
"ifInUcastPkts_prev": 0,
"ifInUcastPkts_delta": null,
"ifInUcastPkts_rate": null,
"ifOutUcastPkts": 11237,
"ifOutUcastPkts_prev": 0,
"ifOutUcastPkts_delta": null,
"ifOutUcastPkts_rate": null,
"ifInErrors": 0,
"ifInErrors_prev": 0,
"ifInErrors_delta": null,
"ifInErrors_rate": null,
"ifOutErrors": 0,
"ifOutErrors_prev": 0,
"ifOutErrors_delta": null,
"ifOutErrors_rate": null,
"ifInOctets": 13649082,
"ifInOctets_prev": 0,
"ifInOctets_delta": null,
"ifInOctets_rate": null,
"ifOutOctets": 1226171,
"ifOutOctets_prev": 0,
"ifOutOctets_delta": null,
"ifOutOctets_rate": null,
"poll_prev": null,
"ifInNUcastPkts": 66399,
"ifInNUcastPkts_prev": 0,
"ifInNUcastPkts_delta": null,
"ifInNUcastPkts_rate": null,
"ifOutNUcastPkts": 19,
"ifOutNUcastPkts_prev": 0,
"ifOutNUcastPkts_delta": null,
"ifOutNUcastPkts_rate": null,
"ifInDiscards": 0,
"ifInDiscards_prev": 0,
"ifInDiscards_delta": null,
"ifInDiscards_rate": null,
"ifOutDiscards": 0,
"ifOutDiscards_prev": 0,
"ifOutDiscards_delta": null,
"ifOutDiscards_rate": null,
"ifInUnknownProtos": 0,
"ifInUnknownProtos_prev": 0,
"ifInUnknownProtos_delta": null,
"ifInUnknownProtos_rate": null,
"ifInBroadcastPkts": 0,
"ifInBroadcastPkts_prev": 0,
"ifInBroadcastPkts_delta": null,
"ifInBroadcastPkts_rate": null,
"ifOutBroadcastPkts": 0,
"ifOutBroadcastPkts_prev": 0,
"ifOutBroadcastPkts_delta": null,
"ifOutBroadcastPkts_rate": null,
"ifInMulticastPkts": 0,
"ifInMulticastPkts_prev": 0,
"ifInMulticastPkts_delta": null,
"ifInMulticastPkts_rate": null,
"ifOutMulticastPkts": 0,
"ifOutMulticastPkts_prev": 0,
"ifOutMulticastPkts_delta": null,
"ifOutMulticastPkts_rate": null
}
]
}
},
"sensors": {
"discovery": {
"sensors": [
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.1",
"sensor_index": "rPDUOutletMeteredStatusIndex.1",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 1, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.10",
"sensor_index": "rPDUOutletMeteredStatusIndex.10",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 10, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.11",
"sensor_index": "rPDUOutletMeteredStatusIndex.11",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 11, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.12",
"sensor_index": "rPDUOutletMeteredStatusIndex.12",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 12, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.13",
"sensor_index": "rPDUOutletMeteredStatusIndex.13",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 13, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.14",
"sensor_index": "rPDUOutletMeteredStatusIndex.14",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 14, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.15",
"sensor_index": "rPDUOutletMeteredStatusIndex.15",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 15, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.16",
"sensor_index": "rPDUOutletMeteredStatusIndex.16",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 16, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.17",
"sensor_index": "rPDUOutletMeteredStatusIndex.17",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 17, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.18",
"sensor_index": "rPDUOutletMeteredStatusIndex.18",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 18, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.19",
"sensor_index": "rPDUOutletMeteredStatusIndex.19",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 19, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.2",
"sensor_index": "rPDUOutletMeteredStatusIndex.2",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 2, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.20",
"sensor_index": "rPDUOutletMeteredStatusIndex.20",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 20, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.21",
"sensor_index": "rPDUOutletMeteredStatusIndex.21",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 21, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.22",
"sensor_index": "rPDUOutletMeteredStatusIndex.22",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 22, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.23",
"sensor_index": "rPDUOutletMeteredStatusIndex.23",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 23, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.24",
"sensor_index": "rPDUOutletMeteredStatusIndex.24",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 24, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.3",
"sensor_index": "rPDUOutletMeteredStatusIndex.3",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 3, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.4",
"sensor_index": "rPDUOutletMeteredStatusIndex.4",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 4, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.5",
"sensor_index": "rPDUOutletMeteredStatusIndex.5",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 5, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.6",
"sensor_index": "rPDUOutletMeteredStatusIndex.6",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 6, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.7",
"sensor_index": "rPDUOutletMeteredStatusIndex.7",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 7, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 1,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.8",
"sensor_index": "rPDUOutletMeteredStatusIndex.8",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 8, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.6.9",
"sensor_index": "rPDUOutletMeteredStatusIndex.9",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 9, Current",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "current",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.120.2.1.4.1",
"sensor_index": "rPDUPhaseStatusIndex.1",
"sensor_type": "dell-rpdu",
"sensor_descr": "Current, Phase #1",
"group": null,
"sensor_divisor": 10,
"sensor_multiplier": 1,
"sensor_current": 19.3,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.1",
"sensor_index": "rPDUOutletMeteredStatusIndex.1",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 1, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 250,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.10",
"sensor_index": "rPDUOutletMeteredStatusIndex.10",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 10, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 276,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.11",
"sensor_index": "rPDUOutletMeteredStatusIndex.11",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 11, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 113,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.12",
"sensor_index": "rPDUOutletMeteredStatusIndex.12",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 12, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 90,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.13",
"sensor_index": "rPDUOutletMeteredStatusIndex.13",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 13, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 95,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.14",
"sensor_index": "rPDUOutletMeteredStatusIndex.14",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 14, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 273,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.15",
"sensor_index": "rPDUOutletMeteredStatusIndex.15",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 15, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 267,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.16",
"sensor_index": "rPDUOutletMeteredStatusIndex.16",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 16, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.17",
"sensor_index": "rPDUOutletMeteredStatusIndex.17",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 17, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 172,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.18",
"sensor_index": "rPDUOutletMeteredStatusIndex.18",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 18, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 146,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.19",
"sensor_index": "rPDUOutletMeteredStatusIndex.19",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 19, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 173,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.2",
"sensor_index": "rPDUOutletMeteredStatusIndex.2",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 2, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 250,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.20",
"sensor_index": "rPDUOutletMeteredStatusIndex.20",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 20, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 181,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.21",
"sensor_index": "rPDUOutletMeteredStatusIndex.21",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 21, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.22",
"sensor_index": "rPDUOutletMeteredStatusIndex.22",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 22, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 163,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.23",
"sensor_index": "rPDUOutletMeteredStatusIndex.23",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 23, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 52,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.24",
"sensor_index": "rPDUOutletMeteredStatusIndex.24",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 24, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.3",
"sensor_index": "rPDUOutletMeteredStatusIndex.3",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 3, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 352,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.4",
"sensor_index": "rPDUOutletMeteredStatusIndex.4",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 4, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 239,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.5",
"sensor_index": "rPDUOutletMeteredStatusIndex.5",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 5, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 271,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.6",
"sensor_index": "rPDUOutletMeteredStatusIndex.6",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 6, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 235,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.7",
"sensor_index": "rPDUOutletMeteredStatusIndex.7",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 7, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 99,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.8",
"sensor_index": "rPDUOutletMeteredStatusIndex.8",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 8, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 0,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.8.9",
"sensor_index": "rPDUOutletMeteredStatusIndex.9",
"sensor_type": "dell-rpdu",
"sensor_descr": "Outlet, Outlet 9, Power",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 57,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "power",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.120.2.1.6.1",
"sensor_index": "rPDUPhaseStatusIndex.1",
"sensor_type": "dell-rpdu",
"sensor_descr": "Power, Phase #1",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 10,
"sensor_current": 3810,
Remove guessed limits for some health sensors, documentation for sensor classes (#10327) * Default to null for group yaml discovery. * Update test data for a154bda yaml group null fix. * Changes to guessed limit functions for sensors. Original behaviour =================== The file `includes/discovery/functions.inc.php` contains `sensor_limit_low()` and `sensor_limit()` which both attempt to guess a sane value for sensors when no explicitly defined low_limit or high_limit can be found during discovery. Both switch control structures used in those two functions have empty case statements which means that if one of those matches, it's going to fall through and run the code for each subsequent case until a `break` is reached. For example, when we call `function sensor_low_limit(dbm, -13.036)` it will return the value `-12.3842` instead of `null`. That is because there will be a match at `case 'dbm':` which falls through all the way to `case 'cooling':`, where it performs `$limit = -13.036 * 0.95` before hitting a `break`. Changed behaviour =================== Removed `power_consumed` and `count` guessed low_limit and high_limit, I personally added those sensor classes in PR #9471 when I didn't understand that a switch control structure has fall-through behaviour so I can guarantee that guessing limits for those is a mistake on my behalf. It should not be there, only power_factor can have guessed limits. Apologies for the issue, I'm still a beginning programmer! Furthermore, I removed guessed high_limit values for `current` and `power` because these are supposed to draw higher values as more devices or components are installed on for example a PDU or a chassis. Finally, I removed guessed low_limit and high_limit for `dbm` sensors, there is a much too large variance in power budget on commercially available optical transceivers for there to be a sensible window where you can guess these values. * Documentation on adding sensor classes. * Update test data - sensor limit changes @ 30212d2
2019-06-21 14:03:27 +00:00
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.110.2.1.6.1",
"sensor_index": "rPDUDeviceStatusLoadState.1",
"sensor_type": "rPDUDeviceStatusLoadState",
"sensor_descr": "Device State",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUDeviceStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.1",
"sensor_index": "rPDUOutletMeteredStatusIndex.1",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 1, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.10",
"sensor_index": "rPDUOutletMeteredStatusIndex.10",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 10, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.11",
"sensor_index": "rPDUOutletMeteredStatusIndex.11",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 11, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.12",
"sensor_index": "rPDUOutletMeteredStatusIndex.12",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 12, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.13",
"sensor_index": "rPDUOutletMeteredStatusIndex.13",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 13, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.14",
"sensor_index": "rPDUOutletMeteredStatusIndex.14",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 14, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.15",
"sensor_index": "rPDUOutletMeteredStatusIndex.15",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 15, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.16",
"sensor_index": "rPDUOutletMeteredStatusIndex.16",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 16, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.17",
"sensor_index": "rPDUOutletMeteredStatusIndex.17",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 17, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.18",
"sensor_index": "rPDUOutletMeteredStatusIndex.18",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 18, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.19",
"sensor_index": "rPDUOutletMeteredStatusIndex.19",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 19, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.2",
"sensor_index": "rPDUOutletMeteredStatusIndex.2",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 2, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.20",
"sensor_index": "rPDUOutletMeteredStatusIndex.20",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 20, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.21",
"sensor_index": "rPDUOutletMeteredStatusIndex.21",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 21, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.22",
"sensor_index": "rPDUOutletMeteredStatusIndex.22",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 22, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.23",
"sensor_index": "rPDUOutletMeteredStatusIndex.23",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 23, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.24",
"sensor_index": "rPDUOutletMeteredStatusIndex.24",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 24, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.3",
"sensor_index": "rPDUOutletMeteredStatusIndex.3",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 3, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.4",
"sensor_index": "rPDUOutletMeteredStatusIndex.4",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 4, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.5",
"sensor_index": "rPDUOutletMeteredStatusIndex.5",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 5, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.6",
"sensor_index": "rPDUOutletMeteredStatusIndex.6",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 6, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.7",
"sensor_index": "rPDUOutletMeteredStatusIndex.7",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 7, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.8",
"sensor_index": "rPDUOutletMeteredStatusIndex.8",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 8, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.130.2.2.1.11.9",
"sensor_index": "rPDUOutletMeteredStatusIndex.9",
"sensor_type": "rPDUOutMeteredStatusLoadState",
"sensor_descr": "Outlet, Outlet 9, Load",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 2,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUOutMeteredStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "state",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.120.2.1.3.1",
"sensor_index": "rPDUPhaseStatusLoadState.1",
"sensor_type": "rPDUPhaseStatusLoadState",
"sensor_descr": "Load State, Phase #1",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 3,
"sensor_limit": null,
"sensor_limit_warn": null,
"sensor_limit_low": null,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": "rPDUPhaseStatusLoadState"
},
{
"sensor_deleted": 0,
"sensor_class": "voltage",
"poller_type": "snmp",
"sensor_oid": ".1.3.6.1.4.1.674.10903.200.2.200.120.2.1.5.1",
"sensor_index": "rPDUPhaseStatusIndex.1",
"sensor_type": "dell-rpdu",
"sensor_descr": "Voltage, Phase #1",
"group": null,
"sensor_divisor": 1,
"sensor_multiplier": 1,
"sensor_current": 205,
"sensor_limit": 235.75,
"sensor_limit_warn": null,
"sensor_limit_low": 174.25,
"sensor_limit_low_warn": null,
"sensor_alert": 1,
"sensor_custom": "No",
"entPhysicalIndex": null,
"entPhysicalIndex_measured": null,
"sensor_prev": null,
"user_func": null,
"state_name": null
}
],
"state_indexes": [
{
"state_name": "rPDUDeviceStatusLoadState",
"state_descr": "lowLoad",
"state_draw_graph": 1,
"state_value": 1,
"state_generic_value": 0
},
{
"state_name": "rPDUDeviceStatusLoadState",
"state_descr": "normal",
"state_draw_graph": 1,
"state_value": 2,
"state_generic_value": 0
},
{
"state_name": "rPDUDeviceStatusLoadState",
"state_descr": "nearOverload",
"state_draw_graph": 1,
"state_value": 3,
"state_generic_value": 1
},
{
"state_name": "rPDUDeviceStatusLoadState",
"state_descr": "overload",
"state_draw_graph": 1,
"state_value": 4,
"state_generic_value": 2
},
{
"state_name": "rPDUOutMeteredStatusLoadState",
"state_descr": "lowLoad",
"state_draw_graph": 1,
"state_value": 1,
"state_generic_value": 0
},
{
"state_name": "rPDUOutMeteredStatusLoadState",
"state_descr": "normal",
"state_draw_graph": 1,
"state_value": 2,
"state_generic_value": 0
},
{
"state_name": "rPDUOutMeteredStatusLoadState",
"state_descr": "nearOverload",
"state_draw_graph": 1,
"state_value": 3,
"state_generic_value": 1
},
{
"state_name": "rPDUOutMeteredStatusLoadState",
"state_descr": "overload",
"state_draw_graph": 1,
"state_value": 4,
"state_generic_value": 2
},
{
"state_name": "rPDUPhaseStatusLoadState",
"state_descr": "lowLoad",
"state_draw_graph": 1,
"state_value": 1,
"state_generic_value": 0
},
{
"state_name": "rPDUPhaseStatusLoadState",
"state_descr": "normal",
"state_draw_graph": 1,
"state_value": 2,
"state_generic_value": 0
},
{
"state_name": "rPDUPhaseStatusLoadState",
"state_descr": "nearOverload",
"state_draw_graph": 1,
"state_value": 3,
"state_generic_value": 1
},
{
"state_name": "rPDUPhaseStatusLoadState",
"state_descr": "overload",
"state_draw_graph": 1,
"state_value": 4,
"state_generic_value": 2
}
]
},
"poller": "matches discovery"
}
}