In this experiment is created an interactive interface that displays real-time heart―rate and sleep tracking data from a Fitbit Charge HR.

Introduction

In this article we will explore how you can use your Fitbit data to create an interactive interface from scratch. Fitbit is an activity trackers, wireless-enabled wearable technology devices that measure data such as the number of steps walked, heart rate, quality of sleep, steps climbed, and other personal metrics, the model used is Charge HR (i.e. heart rate). You can see a quick demo of the final result in the embedded codepen below. The technologies used are HTML, CSS, javascript (jQuery), SVG, the OAuth 2.0 protocol and some RESTful calls in order to retrieve the Fitbit raw data. We will discuss first the general concept, the why and the hows. This article is focused on the front―end part while the resting back-end implementation is let to a future implementation. The sole scope is to build a final working prototype. The experiment interface is intended to be used in a real web site once tested and completed.

Interface
The interface is composed by two elements, the heart―rate module and the sleep module. In the heart―rate module will be displayed the average heart―rate and the heart graph. In the sleep module will be displayed the daily hours slept per night of the last week and the average hours slept. In image below is shown the prototype of the desired final result. In order to create the heart icon, the heart graph and the sleep graph, SVG images are our perfect choice. This image format allow us to make animations by changing it’s attributes/points/shapes in a very easy way through JavaScript or CSS. For animating the heart icon, the simplest way of doing it is through CSS3 (i.e. @keyframes and it’s animation features). To simulate the heart beat we can increase and then decrease the width and height of the heart icon at a fixed period of time. Lastly we can simply change the animation speed time at runtime (i.e. the animation-duration CSS3 property). Let’s make some math: the data that Fitbit provides are heart beats per minute (hbpm). For example 60 hbpm is read as 60 heart beats in 1 minute, that means that in one second our heart icon should make an animation (i.e. animation-duration:1s; ). You may already noticed that we are not interested in the hbpm, but in how many seconds it takes to make a heart beat (per second heart beat). In short we divide 60 seconds by the number of hbpm (e.g. 60s / 80hbpm = 0,75s , animation-duration:0,75s; ). The last modules and icons are updated and animated through JavaScript.
Code & Logic

We briefly explain the JavaScript code necessary to create the animations, fetch, display the data and so on. The code can be found in the codepen at the introduction section example above. As explained previously, the back-end part is not explained in this article, for the moment we provide the raw data received in JSON format using the Fitbit APIs. The jQuery library is used in order to manipulate the DOM. The JavaScript code is structured two modules, the basic pattern used are Iterator and Module pattern.

OAuth 2.0 & Fitbit Charge HR

The data that is normally collected from your Fitbit tracker can’t be accessed directly from your device (that’s sad). First you need to connected to your mobile device or computer, then you need an internet connection and then the data is send to Fitbit central server. Luckily Fitbit provides some APIs for the developers which you can use to get the desired data. In order to use the Fitbit APIs (e.g. https://api.fitbit.com/1/user/3WZ68J/activities/heart/date/2016-06-18/1d/1sec/time/00:00/23:59.json ), you first need to register as a developer at https://dev.fitbit.com , then get a token and an authorisation code in order to be able to use and get the data. Once you have the application name, token and secret code you can make a request using the OAuth protocol to get the data. The OAuth protocol is used for the API usage grant, not for the authentication. If you would like to know more about the protocol you are invited to look at the official RFC or documentation. Usually an user stays at average from 5 seconds to max 10 minutes on a website (the range changes based on the type of the website), there is no need to get all intraday heart rate data, we just grab once a day the yesterday data or the last available data. Instead of making API calls at every single HTTP request make just one call a day and get the yesterday data. You also need a token to make a request, I’ve made a year token (though that’s a bad security practice) for the moment to not worry about updating the token.

Conclusion

It would be nice to have real time data, unfortunately that is not possibile due to the fact that the data first need to go through a central server and there is now direct way to fetch the data from the device directly. Future implementation of the back-end fetch data is not yet implemented and may lead to new challenges. The heart rate data could also be used as seed for some random animation or functions.