ActivityWatch as a data aggregator

I’ve started to realize that one thing I’m really wanting for in my quantified self experiments is a data aggregation platform. By this I mean a single database that I can send all my data to so that it is stored safely and is easily accessible. This data would include computer/phone usage data from activitywatch, but also sleep data, nutrition data, physical activity data, etc.

Activitywatch seems built to store general data like this. As such I’ve started writing watchers to pull in data from these sources and visualizations that work with this differently typed data. At this point, I wanted to take a step back as ask if anyone else has gone down this path before, or if there is anything that I should know about why this maybe isn’t the best use of Activitywatch.

I think the one main caveat with AW is that syncing isn’t available yet, and a central server running in the cloud or on a dedicated server machine is not well supported, so I will be restricted to messing with my data from a single PC.

Some other platforms that attempt to solve this problem:


I’m not sure if these platforms are really better than AW in any specific way, especially if I’m already using AW to track my computer/phone usage.

@erikbjare Is also quite into quantified self and if i recall correctly has been talking a bit with the zenobase founder a bit a while ago.

I have not heard of heedy before though, but seems to only be for fitness trackers?

I think the major issue here is that there is no standardized format for digital activity. The best solution in my opinion would be if there was some standard format which then in turn could be automatically synced to a platform that aggregates it all.

While ActivityWatch “could” be that central hub, it’s not designed for it and would probably be a bad fit for some types of metrics if we didn’t significantly change the design.

So far it seems like AW/heady/zenobase all basically have the same data model - raw json or key/value dict structures. I don’t have a problem writing parsers to ingest different types of data into this format, so I’m not really worried about making sure my app has proper support for some standardized format. Probably the bigger win for me would be if an app has ready-built visualization for certain data. But honestly I kinda like the flexibility of building my own visualizations on the fly using code.

Maybe I’m biased since I’ve invested some time already hacking on activity watch (and it seems to work for my purposes so far even with health/nutrition/sleep data). I’m just a bit worried that there is some big issue I haven’t run into yet that I’m missing, or if someone has tried this already and abandoned it, or if someone has tried this kind of thing already and has code I can use!

Did you have anything specific in mind when you said “would probably be a bad fit for some types of metrics if we didn’t significantly change the design”?

I’ve been tempted by this too, but ultimately haven’t gone very far with it due to concerns similar to the ones @johan-bjareholt raises. Without going into the specifics of why it might not be a good fit, we’ve simply not designed for it, and I can’t imagine that it is a good fit by accident.

It is true that ActivityWatch has a very flexible data model (indeed inspired in part by Zenobase), and ActivityWatch could store and process any data on a timestamped format, but, should it?

Somewhere we need to draw a line in the sand and say what ActivityWatch is and what it isn’t to avoid scope creep. We will for the foreseeable future stay focused on the same things we’re focused on now, and not other types of data. However, we will stay open to the possibility of it collecting more types of data over time, through both watchers and importers.

You might also want to have a look at: