Fedora ARM server future use case - Fitness dashboard

[Hanku Lee]

Most fitness enthusiasts have favorite apps to track activities and
share with friends. Often, advanced features need a paid membership.
Still, it is limited to fixed features and I get distracted or let
down by certain features, which I don't need. Feature mismatch
persists.

I have 7+ years of fitness data in Strava. The main sport is cycling.
I want to keep the data in my control and design a custom dashboard
using the Fedora server and R Pi. It's not huge data, so I'll stay
away from the cloud. This is proof of concept if I want to expand this
further in the future.

[Objectives]
Build data pipeline with fitness API (start with Strava).
Set up a database server on R Pi.
Write SQL scripts for data ingest and metrics.
Add Python scripts for calculation and display,
Connect to Dash apps (or equivalent open-source analytics tool).
(Optional) Expand data source to fitness sensors (cycling computer and
Heart rate monitor) for richer metrics.

Will this be of any use or interest to the Fedora community?

Happy Thanksgiving day!

Reference
https://developers.strava.com/docs/reference/
https://plotly.com/dash/

[Peter Boy]

>  Am 23.11.2021 um 23:16 schrieb Hanku Lee
> <hanku.lee(a)gmail.com&gt;:
>  
>  Most fitness enthusiasts have favorite apps to track activities and
>  share with friends. Often, advanced features need a paid membership.
>  Still, it is limited to fixed features and I get distracted or let
>  down by certain features, which I don't need. Feature mismatch
>  persists. 
I'm plenty annoyed with many fitness tracker manufacturers who force consent to store
all data with the manufacturer after purchase in order to use the device at all. Others
allow only very basic use without consent to data storage. In fact, others offer only very
sparse and inflexible data evaluation options. This even applies to Apple, which are quite
elaborate after all. And above all, they offer very limited export and exchange options,
unless you want to resort to proprietary and manufacturer-owned data repositories. 

There is no technical reason to store the data on your own hardware. You "only"
have to take it in hand. 

Fedora Server with its reliable service and in combination with other open source tools
(e.g. R for graphical and statistical analysis), and all that power on an SBC would be a
wonderful, affordable appliance. 

I think this would be an excellent and especially innovative use case.


>  I have 7+ years of fitness data in Strava. The main sport is
> cycling.
>  I want to keep the data in my control and design a custom dashboard
>  using the Fedora server and R Pi. It's not huge data, so I'll stay
>  away from the cloud. This is proof of concept if I want to expand this
>  further in the future. 
I'm most attracted to "data in my control“. :-)

>  
>  [Objectives]
>  Build data pipeline with fitness API (start with Strava).
>  Set up a database server on R Pi.
>  Write SQL scripts for data ingest and metrics. 
It’s a question of details, but instead of SQL scripting you might use an
object-relational mapping tool. In java it would be Hibernate, for Python there are
equivalent libraries, I think.

>  ...
>  (Optional) Expand data source to fitness sensors (cycling computer and
>  Heart rate monitor) for richer metrics. 
I suspect that would be the "hard part'" 


>  https://plotly.com/dash/ 
Are you sure that this is an open source project? If it already says "pricing"
in the main menu …  

Again, in Java I know several open source projects (e.g. based on Netbeans infrastructure
that includes powerful backend capabilities). But certainly there are a lot of truly open
source projects in Python as well. 

A very interesting project.

[Hanku Lee]

>  There is no technical reason to store the data on your own hardware.
> You "only" have to take it in hand. 
The head unit (like a cycling computer that is connected to sensors) can disable
auto-upload activities. What I'm trying to do is to transfer the ride data via the
Bluetooth communications module to save on to a database. I want to bypass uploading to
the manufacturer's cloud service.

>  Instead of SQL scripting you might use an object-relational mapping
> tool. In java it would be Hibernate, > for Python, there are equivalent libraries, I
> think. 
Fair enough. I mean SQL in generic terms (any data query language). Python libraries have
plenty of data tools. Ride data is saved in XML format (time and geospatial data), the
efficient way to parse XML files in Python will be considered.

There are two parts to this - parsing historical data by fitness API, which is provided by
Strava, Wahoo, and the like. The other one is to get live feed from the head unit/sensors,
which is the hard part.

Plotly provides an open-source free version and enterprise paid license. I couldn't
find the license agreement. I think depending on a choice of database engine and data
pipeline, the analytics tool is aplenty.

Thanks for sharing your insights and advice.

[Peter Robinson]

Hi Hanku,

>  Most fitness enthusiasts have favorite apps to track activities and
>  share with friends. Often, advanced features need a paid membership.
>  Still, it is limited to fixed features and I get distracted or let
>  down by certain features, which I don't need. Feature mismatch
>  persists.
>
>  I have 7+ years of fitness data in Strava. The main sport is cycling.
>  I want to keep the data in my control and design a custom dashboard
>  using the Fedora server and R Pi. It's not huge data, so I'll stay
>  away from the cloud. This is proof of concept if I want to expand this
>  further in the future. 
TBH this isn't necessarily a Fedora Server specific thing, it could
also be Fedora IoT or general Fedora.

>  [Objectives]
>  Build data pipeline with fitness API (start with Strava).
>  Set up a database server on R Pi.
>  Write SQL scripts for data ingest and metrics.
>  Add Python scripts for calculation and display,
>  Connect to Dash apps (or equivalent open-source analytics tool).
>  (Optional) Expand data source to fitness sensors (cycling computer and
>  Heart rate monitor) for richer metrics. 
I would change a lot of the above, like why SQL, a time series DB may
be better for that sort of data.

>  Will this be of any use or interest to the Fedora community? 
I'm sure a general project like this would of wider interest than just
Fedora Server, or even just Fedora.

There's even interest in removing the closed ecosystem such as Strava
for health data entirely so why just limit it to the ability to
visualise data from a proprietary service/stack.

There's PineTime [1] with an open source firmware called IniniTime [2]
with an open GTK3 app to run on Linux [3] so why not go the whole way?

I suggest taking this to the wider fedora devel list.

Peter

[1] https://wiki.pine64.org/index.php/PineTime
[2] https://github.com/InfiniTimeOrg/InfiniTime
[3] https://github.com/alexr4535/siglo

[Hanku Lee]

Hi Peter,

>  TBH this isn't necessarily a Fedora Server specific thing, it
> could also be Fedora IoT or general Fedora. 
Fair enough. It may well be suited better for Fedora IoT, which I'm not familiar.

>  I would change a lot of the above, like why SQL, a time series DB may
> be better for that sort of data. 
True. The choice of database engine will be much affected by types of data (time and
geospatial) and data pipeline. I need to work with XML data.

>  There's even interest in removing the closed ecosystem such as
> Strava for health data entirely so why just limit it to the ability to visualise data from
> a proprietary service/stack. 
My goal is to bypass the service provider/manufacturer's data collection and
processing. I should explore a little more about open-source visualization tools.

>  There's PineTime [1] with an open source firmware called
> IniniTime [2] with an open GTK3 app to run on Linux [3] so why not go the whole way?
Good point.

[Hanku Lee]

I would also need to consider repurposing the android-powered cycling computer I have.

Due to diverse sets of data fields (80+), cycling sensors connected, onboard maps, and
other safety features of the device, I would look to open-source custom images to flash
the device, alternatively. I found a custom image supported by the manufacturer, and [2]
Open Bike Computer with GPL v3 license.

[1] https://gist.github.com/Intyre/2c0a8e337671ed6f523950ef08e3ca3f
[2] https://github.com/wentam/OBC