I could be wrong here, but as far as I can see from https://github.com/espruino/BangleApps/blob/master/apps/sleeplog/boot.js#L27 sleep log mainly uses the 10 minute 'movement' value from the built-in health event.

This is great because it's not really using any extra power, but also the health app is already storing this information too, all the time. And it's synced already via the {t:'act', mov:...} - we may just not be storing it in Gadgetbridge?

... so in a way, we may just be able to run this algorithm on data that's already in gadgetbridge? Looks like sleeplog does check wear state and whether it's charging though, which we don't store (but charge state at the very least could be sent/stored trivially, and I guess if it's not worn we won't have a BPM reading for that 10 min health event).

That's one thought, but also sleeplog saves everything to a storage file. Perhaps we should consider having some kind of generic file sync built into Gadgetbridge rather than setting out to do it just for sleeplog?

• metadata.json already has a data field listing data files the apps make. Maybe if sync:true is set there, we could make sure that's pushed through to appname.info in the bangle
• when syncing Gadgetbridge could scan those files and figure out a list of files to sync, and could then automatically sync them

Espruino has two different storage types (one fixed length and binary, one appendable and text). There's already the code to handle syncing the appendable one for tracks thanks to @thyttan, but I guess we might need to add something to deal with the binary one.

Off topic:

@gfwilliams

This is great because it's not really using any extra power

I also like this aspect of sleeplog. But every time I use it for a while I end up suspecting the app of being a big drain on battery somehow. Do you have this experince as well? Could it be writes to storage? I haven't looked at this deeply yet (and don't know if I ever will).

I haven't used it I'm afraid - but it depends how big the sleeplog JSON file is - if it is big it could end up being a huge drain.

Using StorageFile for stuff that gets appended to would be the way to go... Or actually we could extend the 'health' app's file format with extra fields.

• battery and wear state would be a good one
• we could also have a field for 'activity type' which apps could update, so sleeplog could just update that and then it'd be saved automatically. Similarly the 'run' app could automatically set activity type when it's running, the cycle app, and so on.

I feel like having some kind of global activity state would probably fit better with what Gadgetbridge expects?

If we extended the 'health' file format that way, would that mean we could refactor sleeplog to just display data from the 'health' file? Sounds pretty neat.

would that mean we could refactor sleeplog to just display data from the 'health' file?

Yes - it'd still have to run over the data from the day and count up all the moments of sleep and how long and so on, but it'd just be a case of looking at whether activityType==DEEP_SLEEP and so on.

but it depends how big the sleeplog JSON file is - if it is big it could end up being a huge drain.

I just checked again and I was totally wrong here. It uses StorageFile already so that should really have no big effect on power usage no matter how big the file gets.

... so in a way, we may just be able to run this algorithm on data that's already in gadgetbridge?

One one hand, this would work for the current implementation. On the other, I'm left wondering if this would prevent the algorithm from being improved (eg. taking small bursts of real-time data like Sleep as Android does).

I feel like having some kind of global activity state would probably fit better with what Gadgetbridge expects?

I do like this idea, but I'm not sure we should just think about what Gadgetbridge expects :) its current implementation is driven by how the first gadgets that needed saved data, which is not always the most efficient or easier to work with format. It might also be a bit heavier on the Bangle side storage-wise, as we'd need to keep the sleep state for every 10-minute block, instead of a sleep range "from X time to Y" (I did not check how the current sleep log app saves it).

We have been having to merge the data from multiple sources for some gadgets (steps from a table, heart rate from another, sleep from another), so that's not really a problem.

It might also be a bit heavier on the Bangle side storage-wise, as we'd need to keep the sleep state for every 10-minute block

Yes, however right now we store 4 bytes for every 10 minutes, so that's 18kB per month - which isn't a big deal as we have 8MB available. I was thinking maybe we add a bit to that.

• 1 byte could store charge state, wear state, and current activity easily.
• I also fancy storing battery level and altitude (packed into 2 bytes)

Not sure if there's anything else?

Pinging @storm64 again in case you missed the first one. What's your thoughts on the discussion here?

@storm64 ?