Solution for Capturing Data from Wearable Devices

: Thanks to the rise of wearable devices, people have more direct access to a variety of health data, such as physical activity, sleep and heart rate. For the research field, these devices represent a powerful tool for monitoring and evaluating different parameters. However, the procedure of capturing data for storage in an independent and self-managed database is not standardised. In this project we analysed two methods of data capture for the Xiaomi Mi Bands. One uses the official application together with Google Fit and the other uses the open source application GadgetBridge. The advantages and disadvantages of each system were studied, concluding that both could be very beneficial as data capture solutions for wearable devices in research, although with different target projects due to their particularities. Future work will explore these systems in more depth, addressing limitations, automation and optimising for specific research needs.


Introduction
Wearable devices have significantly transformed the field of healthcare, becoming essential tools for personal health monitoring and, increasingly, for biomedical research (Huhn et al., 2022).In the case of activity wristbands, they offer a reliable solution to automatically track health data throughout the day and store it in the cloud.This introduces a novel avenue for monitoring patients' health status within the healthcare sector, potencially allowing, for instance, the automatic detection of health problems (Beniczky et al., 2021;Miranda-duro et al., 2021), the continuous tracking of a patient's progress during treatment (MacEira-Elvira et al., 2019) or the evaluation of sleep patterns to assess sleep quality (Concheiro-Moscoso et al., 2023).One of the key issues when using wearables in research is access to data (Huhn et al., 2022).This aspect is one of the main challenges of this technology (Muzny et al., 2020).Most applications designed to syncing with these devices use cloud-based storage services and do not facilitate data sharing.They also export processed information, making it difficult to perform in-depth analysis with raw data.In addition, providers often employ their own data schemas and use non-standardized, closed transfer protocols (Muzny et al., 2020).All in all, this limits the study and integration of health data and prevents the full potential of these devices from being exploited.
In this context, we present two approaches to retrieve data automatically from fitness trackers, process it and store it in an independent and self-managed database.

Objectives
The main objective of this work is to develop an automatic system for capturing and managing data from Xiaomi Mi Band wristbands for its application in research projects.To this end, we have defined the following specific objectives: 1) to investigate the different forms of access to the data storage location, 2) to convert the captured data into usable information, and 3) to assess the advantages and disadvantages of the analysed systems.

Methodology
In this section we first introduce the wristband model we use and its official application, as well as its limitations regarding data access.Subsequently, we describe two alternative methodologies for data capture: accessing cloud data via Google Fit (Google LLC, 2014) and accessing local data via a separate open-source application, GadgetBridge (Gadgetbridge contributors, 2021).

Xiaomi
Both methods focus on the Xiaomi Mi Band devices (Xiaomi, 2023), one of the most popular and affordable fitness trackers on the market.These devices use sensors to track information such as activity intensity, heart rate, blood oxygen saturation, sleep, training sessions, etc.The data is then stored in ZeppLife (Zepp Health, 2014), one of the official apps provided by the manufacturer for visualisation.
The data is stored in the cloud, on the servers of the provider Huami (Huami, 2023), every time it is synchronised with ZeppLife.It is also stored locally on the mobile device in a restricted access folder, which could only be accessed with a rooted phone.ZeppLife allows exporting the data, but manually and slowly, and already processed in separate CSV files.

Google Fit
The first method involves the Google's Fit REST API (Google Developers contributors, 2023).This API, however, is not supposed to connect to any sensor or wearable.Thus, it is intended to access user data in the fitness store (Nobakht et al., 2020).To use it, it is necessary for each user to have the Google Fit application and a Gmail account.In this case, when using the Xiaomi Mi Smart Band 7, it is also necessary to have the ZeppLife application installed, as the entity responsible for providing the data to Google.
The user synchronizes both applications, enabling Google Fit to read the data stored in Zep-pLife and manage it independently.To make this possible, the use of OAuth 2.0 is required, an authorization protocol that enables a website or application to access resources hosted by other web applications on behalf of a user.In our case, we utilize a temporary access token generated by this tool and associated with the provided Gmail account.As a result, the information recorded by the wristband is accessible through a series of REST queries launched against Google's databases.More specifically, we access recorded data related to: • Physical activity based on the number of steps.
• The duration of each sleep phase (REM, light sleep, deep sleep, or awake) for every sleep session.
• Heart rate in beats per minute.
• The body measurements (weight and height) that the user records.
This requests return the raw data in JSON format, according to the grouping conditions we specify, for then to be processed in our server and stored in our own database in the desired format.A thorough view of the system is displayed in Figure 1.
The reason of using this Google API is its compatibility with almost any type of wearable available on the market, the reliability of having data replicated in an external and trusted database, the API's compatibility with Google's data model and its user-friendly simplicity both for end-users and programming.

Gadgetbridge
The second method is to use the open-source application GadgetBridge as an alternative to ZeppLife.It does not require account registration and data storage on the vendor's servers, instead the data is stored locally on the device in an SQLite database.The steps necessary to implement this system are depicted in Figure 2.
Firstly, the wristbands must be linked to Gadgetbridge.Wristbands communicate with apps via Bluetooth Low Energy (BLE), which uses key-based pairing protocols to establish secure connection sessions.Depending on the model of the wristband there are two different options for pairing.For older models such as the Mi Band 2/3, when GadgetBridge scans the device and orders the pairing, the key is sent without protection from the app to the wristband, and the user confirms the pairing (Casagrande et al., 2022).However, for new models (tested on Mi Band 5/7) the pairing is mediated by Huami's servers.The server signs a pairing key generated from the wristband, based on a random number and the Bluetooth address.The wristband then verifies this signature to establish the pairing, which is confirmed by the user as above (Casagrande et al., 2022).This implies that it is first required to link the wristband to ZeppLife, then obtain this pairing key and use it to link to GadgetBridge, one or more wristbands, as it supports multi-device connection.
The key is stored in a database located in the restricted folder of the ZeppLife application.Hence, an own application was developed (Android Studio Giraffe 2022.3.1) to automatically access this location by activating superuser permissions on a rooted smartphone, and then through an SQL query retrieve the key.Then, the key is inserted manually into GadgetBridge on a different phone and the wristband is permanently paired.
Secondly, once the wristbands are paired, the data can be synchronised and exported from the GadgetBridge application itself.It allows the option to auto-export the data at least every 1 hour and to select the desired destination directory.It is relevant to mention that GadgetBridge has integrated an API to control the Bluetooth connection, synchronisation, and data export via intents (messages for communication between application components).
Regarding the data, with this system an SQLite database is obtained, with multiple tables created for every type of wearable supported by GadgetBridge.Each row represents one record per minute.The registered variables are: • TIMESTAMP: time in Unix format (number of seconds since 00:00:00 UTC 1 January 1970).
• DEVICE ID: identifier of the connected device.
• HEART RATE: beats per minute; when not measured records the value 255.
• RAW INTENSITY: related to the amount of movement, probably data from the accelerometer in the wristband.
• RAW KIND: discrete, device-specific values that are sent processed from the wristband and collected by GadgetBridge.They indicate different situations, for example for the Mi Band 7, the value 155 appears when the wristband is not worn, or the value 120 when there is sleep.
• SLEEP, DEEP SLEEP, REM SLEEP: coded sleep data, as in the previous case.Gadget-Bridge developers set thresholds roughly so that the sleep phases correspond as closely as possible to those shown in ZeppLife (personal communication, GadgetBridge developers).
At the moment, for the Mi Band 5, the registration of sleep variables in the database has not been implemented, although the wristband does record them (personal communication, GadgetBridge developers).Therefore, its data is stored, together with the Mi Band 3 data, in a separate table than the Mi Band 7.

Discussion
Wearable devices are increasingly common among the population offering significant advantages, since the interpretation of this data can be beneficial for the user's health (Beniczky et al., 2021;Concheiro-Moscoso et al., 2023;MacEira-Elvira et al., 2019;Miranda-duro et al., 2021).It is also an interesting topic in research as it allows access to a larger amount of data at relatively low costs (Huhn et al., 2022).For this reason, we proposed two different alternatives for data extraction for research use.Both technologies have been studied, since each one has a way of operating that can be adapted to different requirements.Table 1 provides a summary of the advantages and disadvantages of each of the approaches.
Implementing through the Google's Fit API makes data extraction independent of the wearable device manufacturer and, consequently, of the application they offer for data storage and visualization.If Google Fit can be downloaded on the mobile device and connected to the wearable application, the recorded data is accesible.Furthermore, there is a copy of the information stored in our database hosted on Google servers, and in case any issues arise, the data could be recovered .
On the other hand, using Google Fit as a data source implies the dependence on both device compatibility and its speed and reliability.Although the list of devices compatible with Google Fit is extensive, it is possible that some devices with older software versions may not be compatible with the application.Additionally, the data is only accessible once it has been uploaded to Google's servers, and there is no control over that operation.
The system based on GadgetBridge offers an independent alternative to the official app for data capture.The main advantage of this lies in the improved privacy, as the data remains exclusively on the device, without being stored in the cloud.However, it should be noted that it is not 100% independent from the official app ZeppLife, as it requires obtaining pairing keys from its database, at least with recent models of Mi Band.Although we have solved the problem of obtaining the key, it would be recommendable to test it on more types of wearables.In addition, the server-based type of pairing implies that the two applications are not compatible on the same smartphone.These limitations could be minimised by analysing the vulnerabilities of the official applications and the connection protocols they use.Recently, Casagrande et al. (2022) succeeded in impersonating any Xiaomi fitness tracker and companion app such as ZeppLife.
Regarding the independence of wearable devices, unlike the Google Fit method, Gadget-Bridge only works with the wearables models it has implemented, although they currently cover most of the most popular ones.In relation to this, it should be noted that the fact that it is an open source application allows for its modification, which has already been done in other works (Grossi et al., 2021;Ramachandran et al., 2020).

Conclusions
Despite having identified certain limitations in each of the systems analysed, we consider that the benefits outweigh the associated disadvantages.Therefore, both methodologies can be potentially highly beneficial as data capture systems for wearable devices in the context of research projects, especially by improving automation and minimising potential failures.In addtion, we believe that each can be targeted at different types of projects due to their particularities.
Regarding the Google Fit system, it could be suitable for projects looking for broad compatibility with different wearable devices.Its simplicity of use and familiarity to users also make it an attractive option for projects focused on user convenience.Furthermore, it allows for greater scalability, making it an attractive option for projects anticipating significant growth.In the case of GadgetBridge, it is best suited for projects that place a high priority on data privacy or those that require the simultaneous management and synchronization of multiple wearable devices.Furthermore, in order to fully exploit the potential of this data capture system, it would be advisable to conduct a dedicated study aimed at decoding the encoded variables, both "raw kind" and those related to sleep.Such an investigation could enhance the usability and understanding of the collected data.
In the future, we intend to explore these systems more deeply, focusing on addressing identified limitations, improving automation, and optimizing their usage for specific research needs.

Figure 1 :
Figure 1: Diagram of the Google Fit-Based Capture System

Figure 2 :
Figure 2: Diagram of the GadgetBridge-Based Capture System

Table 1 :
Comparison between methodologies based on Google Fit and Gadgetbridge