<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Ed,<div><br></div><div>What translates the redfish query into a dbus query?</div><div><br></div><div>Mike<br><br><div dir="ltr">Sent from my iPad</div><div dir="ltr"><br><blockquote type="cite">On Jan 11, 2022, at 7:04 PM, Ed Tanous <ed@tanous.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 11, 2022 at 9:53 AM Mike Jones <<a href="mailto:proclivis@gmail.com">proclivis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Ed,<br>
<br>
So to be sure I understand, dbus-sensors implements the dbus services for each sensor type, and the requests I made were serviced by one of these.</blockquote><div dir="auto"><br></div><div dir="auto">Correct.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
The interface is defined by yaml files in phosphor-dbus-interfaces.</blockquote><div dir="auto"><br></div><div dir="auto">Yep.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
phosphor-dbus- interfaces generates c++ base classes, and dbus-sensors probably have c++ classes inheriting from them.</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">For various technical and social reasons which I’ve detailed in mail to this list in the past, dbus-sensors doesn’t depend directly on phosphor-dbus-interfaces, nor rely on the generated code. It instead generates code from c++ template expansion in sdbusplus.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
These interfaces are not Redfish interfaces.</blockquote><div dir="auto"><br></div><div dir="auto">Correct.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
When WebUI fetches sensor values, is it using these interfaces, or is there another Redfish layer involved that translates the query? Or perhaps Redfish only matters for things like a PSU?</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Depends on which webui you’re talking about, there are two.</div><div dir="auto"><br></div><div dir="auto">Phosphor-webui (ie the “old” one) goes directly to dbus through the rest-dbus abstraction in bmcweb. This was very good for initial prototyping (aside from a port to c++, the code largely hasn’t changed since it was written) but not great at keeping a consistent or standardized API.</div><div dir="auto"><br></div><div dir="auto">Webui-vue (ie, the new one) relies on Redfish directly, which in-effect makes a very nice Redfish gui, and minimizes the chance that the dbus interfaces are correct, but redfish is broken. It also keeps us standard compliant, so in theory webui-vue could be used on another non-openbmc project in the future.</div><div dir="auto"><br></div><div dir="auto">Ed</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
<br>
Mike<br>
<br>
<br>
Sent from my iPad<br>
<br>
> On Jan 11, 2022, at 10:22 AM, Ed Tanous <<a href="mailto:edtanous@google.com" target="_blank">edtanous@google.com</a>> wrote:<br>
> <br>
> On Tue, Jan 11, 2022 at 9:17 AM Mike Jones <<a href="mailto:proclivis@gmail.com" target="_blank">proclivis@gmail.com</a>> wrote:<br>
>> <br>
>> This is how to do it:<br>
>> <br>
>> dbus-send --system --print-reply \<br>
>> <br>
>> --dest=xyz.openbmc_project.Hwmon-5a446562b1a2e55ef11da905907088a187a66b71eb7a1f29187594c05bb8fd9a.Hwmon1 \<br>
>> <br>
>> /xyz/openbmc_project/sensors/temperature/lm75temp \<br>
>> <br>
>> org.freedesktop.DBus.Properties.Get string:xyz.openbmc_project.Sensor.Value string:Value \<br>
>> <br>
>> double:<br>
>> <br>
>> <br>
>> It is not clear to me why the second parameter string:Value<br>
>> <br>
>> <br>
>> I guessed on that and it works. Perhaps xyz…Sensor.Value is the Property name, and properties have values, so the second parameter says get the Value of a property whose name ends in .Value.\<br>
> <br>
> For better or worse, the term "Value" is overloaded in both the<br>
> interface name, yz.openbmc_project.Sensor.Value, and the property name<br>
> within the interface, Value. That's why you see it twice in this<br>
> case. They are distinct things within the request that just happen to<br>
> share a name. Docs for the interface and property are here:<br>
> <a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/e0674c894ed36a2e8cf96207907a531d2f514054/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml#L24" rel="noreferrer" target="_blank">https://github.com/openbmc/phosphor-dbus-interfaces/blob/e0674c894ed36a2e8cf96207907a531d2f514054/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml#L24</a><br>
> <br>
> Happy to see you figured it out.<br>
> <br>
>> <br>
>> <br>
>> To test that, I tried string:MaxValue, and that works.<br>
>> <br>
>> <br>
>> I confirmed with this:<br>
>> <br>
>> <br>
>> busctl introspect xyz.openbmc_project.Hwmon-5a446562b1a2e55ef11da905907088a187a66b71eb7a1f29187594c05bb8fd9a.Hwmon1 /xyz/openbmc_project/sensors/temperature/lm75temp<br>
>> <br>
>> <br>
>> A very useful command.<br>
>> <br>
>> <br>
>> Also useful:<br>
>> <br>
>> <br>
>> dbus-send --system --print-reply \<br>
>> <br>
>> --dest=xyz.openbmc_project.ObjectMapper /\<br>
>> <br>
>> xyz/openbmc_project/object_mapper \<br>
>> <br>
>> xyz.openbmc_project.ObjectMapper.GetSubTree \<br>
>> <br>
>> string:"/" int32:0 array:string:"xyz.openbmc_project.Sensor.Value"<br>
>> <br>
>> <br>
>> <br>
>> Mike<br>
>> <br>
>> <br>
>> Sent from my iPad<br>
>> <br>
>> On Jan 10, 2022, at 4:50 PM, Ed Tanous <<a href="mailto:edtanous@google.com" target="_blank">edtanous@google.com</a>> wrote:<br>
>> <br>
>> On Mon, Jan 10, 2022 at 3:47 PM Mike Jones <<a href="mailto:proclivis@gmail.com" target="_blank">proclivis@gmail.com</a>> wrote:<br>
>> <br>
>> <br>
>> Hi,<br>
>> <br>
>> <br>
>> I could not find an example of a sensor query in the docs. I assume something like this:<br>
>> <br>
>> <br>
>> dbus-send --system --print-reply \<br>
>> <br>
>> <br>
>> --dest=xyz.openbmc_project.Hwmon-5a446562b1a2e55ef11da905907088a187a66b71eb7a1f29187594c05bb8fd9a.Hwmon1 \<br>
>> <br>
>> <br>
>> /xyz/openbmc_project/sensors/temperature/lm75temp<br>
>> <br>
>> <br>
>> xyz.openbmc_project.Sensor.Property.Get xyz.openbmc_project.Sensor.Value \<br>
>> <br>
>> <br>
>> double:<br>
>> <br>
>> <br>
>> <br>
>> I don't have an example offhand, but the interface you're looking for<br>
>> in the bolded area is<br>
>> org.freedesktop.DBus.Properties.Get<br>
>> <br>
>> Stack overflow for essentially the same question with an example:<br>
>> <a href="https://stackoverflow.com/questions/48648952/set-get-property-using-dbus-send" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/48648952/set-get-property-using-dbus-send</a><br>
>> <br>
>> <br>
>> With the bold interface replaced with something correct.<br>
>> <br>
>> <br>
>> Can some one give me an example, and a url about how to query properties?<br>
>> <br>
>> <br>
>> Mike<br>
>> <br>
>> <br>
>> Sent from my iPad<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Ed</div></div>
</div></blockquote></div></body></html>