... might not be necessary. Since I got the fetching to work with
intervals on the the Bangle.js side it's been stable.
Didn't manage to make packet counting work yet.
Bangle.js: WIP add supportsActivityTracks
Bangle.js: testing flow of info
Bangle.js:WIP receive and store csv from Bangle.js
Bangle.js:store and transmit ID of last synced log
bangle.js:activity tracks, act on completed fetch
... of the recorder csv file.
Bangle.js: Activity tracks, now in database
... but not all data is persisted correctly I think. It's presented as
'Unknown activity'.
Bangle.js:Activity tracks, try to add gps info
I haven't tested with recordings where I have gps values, so far only
empty values. With empty values I currently get "This activity does not
contain GPX tracks" when trying to use the GPXExporter.
Bangle.js: Activity tracks, now adds GPS points
... to the activity to be shown when on the "Sport Activity Detail"
screen.
This should improve activity parsing across all devices, as we now take
the header into account, which indicates what groups are actually
present.
Thanks to @opcode for figuring out the header structure and providing
the ImHex patterns for the activity data.
Activity data fetching on Huami devices was filled with duplicated code,
and the handleActivityFetchFinish was called from multiple places where
it did not make sense. This made us signal to the band that activity
fetch was finished when it sometimes was not, causing some race
condititions that would make activity fetch fail or get stuck.
This refactor defines a clear "processBufferedData" that is called
upstream, signaling to the fetch operation that we have received all
data and the buffer can be processed. All handling of metadata and ack
messages is also delegated to the upstream class.
Ensure TimeChangeReceiver alarm is scheduled when enabling
datetime_synconconnect and registering TimeChangeReceiver broadcast
receiver.
It is important to re-schedule the alarm after registering broadcast
receiver, because:
1. if broadcast receiver was unregistered while previous alarm arrived,
there is no alarm scheduled;
2. re-scheduling the alarm resets the periodic time sync timer when
first device is connected (which is desired).
It is important to re-schedule the alarm when datetime_synconconnect
gets enabled, because there might be no alarm scheduled.
Call onSetTime() when enabling datetime_synconconnect.
Sync time every 43 hours, 53 minutes and 23 seconds.
Interval is a bit smaller than 2 days.
Interval is a prime (in seconds) so time of sync will slide over time.
If next DST change is less than 48 hours in future, wait for it.
Fixes a typo in the weather forecast characteristic writer that causes
Gadgetbridge to send the current weather twice rather than sending the
forecast.
Zepp OS 3 firmware upgrades are big (200MB+). Gadgetbridge was crashing,
since the entire firmware file would be pulled into memory.
This commit unifies all the logic for Zepp OS firmware handling.
However, since the needed refactor was big, this commit duplicates some
of the code from Huami classes, namely:
- ZeppOsFirmwareUpdateOperation clones UpdateFirmwareOperation2020
- ZeppOsFwInstallHandler clones AbstractMiBandFWInstallHandler
This avoids changes to older device logic and introducing regressions.
Lost functionality:
- Repackaging firmwares as UIHH (does not seem to be needed, and was not
used anyway). Code can be recovered from this commit if needed in the
future
- Whitelisted firmwares by checksum (we do not have a lot of them at
this point anyway)
Other misc changes:
- Rename ZipFile to GBZipFile not to clash with the java class
Tested by updating the Amazfit GTR 4 to Zepp OS 3.
