Push the legacy values as overrides to all subclasses, ensuring that new
devices start with the expected correct behavior.
Overrides can be removed from the subclasses if devices are confirmed to
work without them / not rely on the erroneous behavior.
The previous attempt to send all zeroes (in 7fa5cd1be5) didn't yield actionable progress, hence we try sending back what the watch sent to us.
Blindly implemented based on the legacy vivomoveHR code, not tested against real devices.
Add a Field definition for GPS coordinates and remove the corresponding method from GarminUtils.
Add a new message COURSE and some fields to other known messages.
Also centralize some utility methods in GpxParser and GpxTrack, adapting ZeppOsGpxRouteFile.
Be aware that the capability used to identify the supported watches might be the wrong one.
Our implementation of scale and offset was backwards: we were adding offset and then dividing by scale when decoding fields, but the publicly available protocol description dictates otherwise ( http://web.archive.org/web/20240519102659/https://developer.garmin.com/fit/protocol/#scaleoffset ): "the binary quantity is divided by the scale factor and then the offset is subtracted".
For this reason the sign of GARMIN_TIME_EPOCH in Timestamp field definition must be flipped as well.
Add status message parsing and change the reply logic for watch-initiated Auth (in attempt to fix#3986): before this changeset the phone would reply with a generic ACK and then send a request to the watch for setting the auth (with all zeroes);
after this changeset the phone replies with a specific auth ack/status message but it ignores what the watch requested and acknowledges back all zeroes.
Blindly implemented based on the legacy vivomoveHR code, not tested against real devices.
- Also the sunrise/set cannot be zero
- We could send a single forecast more when exactly 7 are provided
- It seems like the watches may require exactly 8 days to be sent for
the forecast - one of which is for today
