unexpected configuration output given examples

[James Feist]

On 8/14/19 6:16 PM, Patrick Venture wrote:
> On Wed, Aug 14, 2019 at 5:48 PM Patrick Venture <venture at google.com> wrote:
>>
>> When hard-coding bus and addresses, I ran into an interesting issue.
>> Previously, my sensors were dynamically bus'd with hard-coded
>> addresses, like:
>>
>> {
>>      "Exposes": [
>>          {
>>              "Address": "0x1c",
>>              "Bus": "$bus",
>>              "Name": "$bus board local",
>>              "Name1": "$bus board external",
>>              "Type": "TMP441"
>>          },
>> ...
>> }
>>
>> Leads to:
>> xyz.openbmc_project.Configuration.TMP441 interface -         -                 -
>> .Address                                 property  t         28
>>          emits-change
>> .Bus                                     property  t         20
>>          emits-change
>>
>> Which is great.
>>
>> But:
>> {
>>      "Exposes": [
>>          {
>>             "Address": "0x54",
>>             "Bus": 15,
>>             "Name": "$bus i2cool 0",
>>             "Type": "MAX31725"
>>          },
>> ...
>> }
>>
>> Leads to:
>> xyz.openbmc_project.Configuration.MAX31725 interface -         -               -
>> .Address                                   property  s         "0x54"
>>          emits-change
>> .Bus                                       property  t         15
>>          emits-change
>>
>>
>> Which crashes the hwmon temp program because it's "getting" a uint64_t
>> and not a string.
> 
> I verified that if I use decimal for the address as an int it works.
> But I'm interested to know why "0x54" doesn't get converted to an int
> every time?

It's possible some of the changes in review fix this.. I added it as a 
unit test here and it seems to work:

https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/24463

Unless something else in the code is preventing it from getting to the 
replacement function.

> 
>>
>> My only caveat worthwhile is that the hwmon instance is already
>> present because that sensor is in the device-tree.  So I would expect
>> it to only fail on the export.
>>
>> Note, I did also try "Address" as an int and not a string, but that
>> then failed the json validation.
>>
>> Thanks,
>> Patrick