No sensors displayed in webUI

[James Feist]

On 1/15/20 11:27 AM, Patrick Williams wrote:
> On Wed, Jan 15, 2020 at 09:26:48AM -0800, James Feist wrote:
>> There was a thread about this last week:
>>
>> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020044.html
>> https://lists.ozlabs.org/pipermail/openbmc/2020-January/020136.html
>>
>> TL;DR all the sensors are available in Redfish, but the WebUI hasn't move
>> over to full Redfish support yet. There is a test patch that helps enable
>> this in the thread.
> 
> Hi James,
> 
> This statement about a dependency on Redfish stood out to me.  The
> current UI is mostly using the "old" REST API, but as long as the dbus
> objects are created correctly it should not matter one bit if the
> external interface is the dbus-based REST API or the Redfish one.
> 
> This is a bug in dbus-sensors that is independent of Redfish vs REST.
> 
> The current webui code expects there to be properties that are specified
> in phosphor-dbus-interfaces.  Specifically, it is looking for the "Unit"
> property[1], which is a required property on
> xyz.openbmc_project.Sensor.Value[2].  The dbus-sensors has a bunch of
> Sensor.Value objects that are violating the interface spec by not
> providing "Unit" [3].  Notice that `setInitialProperties` doesn't
> register_property on "Unit" and neither does any other code in this
> repository[4].
> 
> Why is none of this code using the code generated from
> phosphor-dbus-interfaces?  Since it is generating dbus objects "by
> hand" it isn't not getting any compile-time checking if it is doing the
> wrong thing (or more likely that the phosphor-dbus-interface changes out
> from underneath it).

There is a long history of this where I tried to get everyone to update 
the sensor value interface to use double instead of INT. I had a large 
agreement, but unfortunately updating all of the daemons that we did not 
use (and without any good way of testing), and trying to get by-in or 
help from all the maintainers became too large of a job. I updated as 
many daemons as I could to accept both before I ran out of time. At the 
same time, I was also phasing out unit, as unit was easy enough to read 
from the sensor path, and redundant information. All of our internal 
daemons don't use phosphor-dbus-interfaces to create interfaces, as we 
have found the code generation difficult to explain to new users, and it 
also makes it difficult to upgrade daemons as all patches need to be 
merged at once. We have been updating interfaces for documentation 
purposes, but haven't used them for any new work in quite some time.


> 
> [1] https://github.com/openbmc/phosphor-webui/blob/f70f42553615972163b36c9b4d77be07e4399122/app/common/services/api-utils.js#L979
> [2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Value.interface.yaml#L32
> [3] https://github.com/openbmc/dbus-sensors/blob/fbb44ad1ea716d4e8c2cacdf01d380c6d0f53855/include/sensor.hpp#L13
> [4] https://github.com/openbmc/dbus-sensors/search?utf8=%E2%9C%93&q=unit&type=
>