generate_profile error: "XLRDError: Excel xlsx file not supported"

[polyvertex]

FIT SDK now comes with Profile.xlsx (previously Profile.xls) so tools/generate_profile.py needs to be updated (using openpyxl?).

As a workaround, it is possible to manually convert Profile.xlsx to the old format and pass it generate_profile directly.

Caution with that though since the resulting profile.py will not contain SDK's version number in its header.

[MeisterP]

I think this was fixed in d20bd54

But tools/generate_profile.py needs work again. Garmin publishes the fit-sdk on github now. See https://github.com/garmin/fit-sdk-tools/blob/main/Profile.xlsx

$ wget https://github.com/garmin/fit-sdk-tools/raw/refs/heads/main/Profile.xlsx
$ python3 tools/generate_profile.py Profile.xlsx fitdecode/profile.py
Traceback (most recent call last):
  File "/Tmp/fitdecode/tools/generate_profile.py", line 679, in <module>
    main(xls, profile)
    ~~~~^^^^^^^^^^^^^^
  File "/Tmp/fitdecode/tools/generate_profile.py", line 657, in main
    str(message_list), ''
    ~~~^^^^^^^^^^^^^^
  File "/Tmp/fitdecode/tools/generate_profile.py", line 177, in __str__
    s += "    %s: %s,\n" % (message.num, indent(message))
                                         ~~~~~~^^^^^^^^^
  File "/Tmp/fitdecode/tools/generate_profile.py", line 105, in indent
    return ('\n%s' % (' ' * (amount * 4))).join(str(s).splitlines())
                                                ~~~^^^
  File "/Tmp/fitdecode/tools/generate_profile.py", line 208, in __str__
    s += "    mesg_num=%d,\n" % self.num
         ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
TypeError: %d format: a real number is required, not str

[ChristophNoetel]

I traced the root cause. The problem is that newer versions of the Garmin FIT SDK Profile.xlsx store some mesg_num values as hex strings (e.g. "0x0008") rather than plain integers.

Data flow:

1. parse_spreadsheet() reads cell values via openpyxl -- integers stay as int, but string values get .encode('ascii') (line 362)
2. parse_types() creates TypeValueInfo with value=maybe_decode(row[3]) -- for hex strings this produces a Python str like "0x0008"
3. get_mesg_num() (line 119-122) returns that string value as-is
4. MessageInfo.__str__() (line 208) uses "mesg_num=%d" % self.num -- crashes with TypeError: %d format: a real number is required, not str

The same issue affects several other %d format sites that receive values from the spreadsheet:

• MessageList.__str__() sort key (line 168): mi.num comparison fails when mixing int and str
• FieldInfo.__str__() (line 227): "def_num=%d" % self.num
• ComponentFieldInfo.__str__() (line 253): "def_num=%d" % self.num
• ReferenceFieldInfo.__str__() (lines 297, 299): "def_num=%d" and "raw_value=%d"

Interestingly, TypeInfo.__str__() (line 148) already handles this correctly:

for value in sorted(self.enum, key=lambda x: x.value if isinstance(x.value, int) else int(x.value, 16)):

Fix: Coerce values to int at parse time rather than patching every format site. The cleanest approach is to handle it in maybe_decode() and get_mesg_num() so that numeric fields (both decimal and hex) are always returned as int. I'll put up a PR.