Ability to distinguish between values from hardware and values set by user

[Krellan]

Currently, in the dbus-sensors D-Bus interface, there is no way to distinguish between sensor values coming in from actual sensor hardware, and sensor values being set in software from the user.

It would be nice to have a way to distinguish this. Perhaps adding an additional field, as was done for the special case of fan PWM percentage sensors, a usage example is here: https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/79824

Without this ability, it can lead to race conditions, such as the user and the hardware fighting over who gets to set the sensor value.

It also leads to ambiguity, especially in the case of fans (or pumps) that are mechanical and take some time to spin up or slow down, This also affects sensors that are quantized to only support a limited number of values in hardware but accept any floating-point number to be written to them. It leads to users wondering why their sensor isn't properly accepting their write request, as the value returned to them on the readback will not match the value they tried to write originally.

It would also be nice to have a way for the user to say "I am finished setting the value of this sensor, please return it to hardware control, and restore the last-known good value from the actual hardware". Currently, there is no way to do this.

The issue here is referring to the supported feature of allowing sensor writes from the user, in the IPMI "Set Sensor Value" command, or the equivalent Redfish command. This issue is similar to, but not the same as, the request for more visibility into the sensor mocking feature, which is something else, utilizing the D-Bus sensor write interface internally, not the IPMI or Redfish layer, and is intended for debugging and testing, not to be exposed to the end user. There's another issue already for that of the sensor mocking feature: #32

[edtanous]

sensor values being set in software from the user.

This is intentional; The "set sensor value" interface for all sensors except external sensor is intended to be a test interface. As a test interface, if it gave a dbus indication that it was "in test", that would defeat the purpose, as client could then detect it was in test mode, and switch in different algorithms that wouldn't properly test the behavior.

such as the user and the hardware fighting over who gets to set the sensor value

Can you be more specific about what hardware we're talking about here? With the exception of External sensor, nothing should be setting a sensor value outside of a test scenario. Maybe you mean the PWM control dbus interfaces? Then I could certainly see a potential for an error. I wonder if that's something we should try to detect in PWMSensor (multiple unique clients trying to set the pwm value). This would only really happen in a configuration error, but it might be good to detect.

I am finished setting the value of this sensor

This was intentionally not done this way given it's a test mode, and the expectation is the BMC would be reset afterward to restore the state, and undo all possible tests that may have corrupted the state machine. If we wanted to add a new interface we could, but I'm not sure what that buys us in a test/development scenario compared to resetting the service/bmc.