Hi! I ran into this on a budget SLUNSE Exercise Bike I bought on Amazon. It advertises the FTMS service UUID (0x1826) but doesn’t include the FTMS service_data in the advertisement. Because of that, pyftms rejected it with NotFitnessMachineError even though, after connecting, the device does expose the FTMS data stream and sends notifications.

Context: I discovered this while trying to integrate the bike into Home Assistant using the FTMS custom component.

This PR lets pyftms still connect and read data in that situation.

I’m not sure how common this pattern is across other devices. I tried to keep the change as generic and low‑risk as possible so it can help similar cases without impacting fully compliant devices.

What I changed:

• Try anyway if FTMS UUID is there: When the advertisement can’t be parsed but the FTMS UUID is present, pyftms now creates a placeholder client and connects.
• Detect the real type after connecting: It checks which FTMS data characteristic is present and notifiable (2AD2/2ACD/2ACE/2AD1) and switches to that machine type/data model.
• Data‑only mode: If the FTMS Feature characteristic is missing, it continues without controls/ranges (still subscribes to the live data stream).
• Subscribe fallback: If subscribing to the first picked data characteristic fails, it falls back to 2AD2 (indoor bike data) when available. This might be a problem if there are other non-bike devices that have the same issue.

Is the placeholder approach okay? It gets corrected right after connect.
I’m not sure this is the best way to solve it; very open to advice, critique, or alternative approaches.

I haven't tested if this fixes the Home Assistant component yet.

Happy to provide any further information or debugging if needed to make a better fix.