tree 2c507444ec8ff8cad3c9cac2aade87aeff69f6f8
parent 4028ff77ddebe603b009a8afaf6bc36bc5949612
author Andrew Geissler <geissonator@yahoo.com> 1636493085 -0600
committer Andrew Geissler <geissonator@yahoo.com> 1636493085 -0600

redfish:sensors: change verbose error trace to debug

It was noticed recently when enabling bmcweb error traces to assist
with some debug, the journal was filling with logs like this:

Nov 09 21:23:46 p10bmc bmcweb[249]: (2021-11-09 21:23:46) [ERROR "sensors.hpp":2584] fan3_1 not in sensor list
Nov 09 21:23:46 p10bmc bmcweb[249]: (2021-11-09 21:23:46) [ERROR "sensors.hpp":2584] fan3_0 not in sensor list
Nov 09 21:23:46 p10bmc bmcweb[249]: (2021-11-09 21:23:46) [ERROR "sensors.hpp":2584] fan4_0 not in sensor list
...

This was the result of a test case reading a single sensor:
curl -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fan4_1

This code logic is fairly complex but appears to get all sensors of the
type passed in, then iterates through them looking for the one(s) of
interest. This code path should not be an error.

Tested:
- Verified that after running the following command, the unwanted logs
  were no longer in the journal:
curl -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fan4_1{
  "@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fan4_1",
  "@odata.type": "#Sensor.v1_0_0.Sensor",
  "Id": "fan4_1",
  "Name": "fan4 1",
  "Reading": 7772.0,
  "ReadingRangeMax": null,
  "ReadingRangeMin": null,
  "ReadingType": "Rotational",
  "ReadingUnits": "RPM",
  "Status": {
    "Health": "OK",
    "State": "Enabled"
  }
}

Change-Id: Iaffd0243ddcd148b72486b3025673bb35d0dd7a3
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>