Open PatrickRudolph opened 6 months ago
Can you give more details here? phosphor-virtual-sensor
generally works, so I'm not following what you're looking for. Is there some configuration that doesn't work?
Updated the issue description. Please let me know if it's still unclear how to reproduce.
Updated the issue description. Please let me know if it's still unclear how to reproduce.
So you want PVS to use its own sensor for additional calculation? I don't think this is possible in an easy way in the current code, even if there were a signal. A dbus daemon can't read its own stuff over dbus (you get an ELOOP). We'd have to add explicit syntax for "get this from an internal sensor object without going to dbus".
I know it isn't pleasant but you can duplicate the PVS config for sensor A as part of sensor B?
Problem description: When phosphor-virtual-sensor is used to create a sensor named
SensorA
, which evaluates to a finite value at construction, it sets theValue
on the Dbus interface. When the calculated value doesn't change, it never emits a dbus property changed event (of course not). The value can be read usingbusctl get-property xyz.openbmc_project.VirtualSensor /xyz/openbmc_project/sensors/xxxx/yyyy xyz.openbmc_project.Sensor.Value Value
and is notnan
.When a second sensor, named
SensorB
is created, that usesSensorA
as DbusParam it will never be able to see a nonnan
value, since:getDbusProperty
after the event loop is running always returns nan, asgetDbusProperty
is blocking and syncronous and the sensor is provided by phosphor-virtual-sensor itself.SensorA
doesn't change it's value, thus never generates a property changed eventNote: For most existing use cases this isn't noticeable since they do not use phosphor-virtual-sensor's sensors as input or the used sensor values change a lot after creation.
Workaround: Add micro noise to phosphor-virtual-sensor's sensors and thus cause multiple unnecessary dbus property change events.
Possible solutions: