GeezerVison

Build size and comparison to main:

Run in InfiniEmu

Sim fix should be trivial, just a method rename it seems

Merged this onto my main device and will try it out compared to the "old"(er) system. Anything to look out for in particular?

I'm most interested in hearing whether it feels natural in terms of how it behaves when you have screen on measurements interacting with background measurements. Also any bugs ofc :)
Thanks for testing!

Two things I can definitely say already:

1. I'm a big fan of the feature that, after about 30 seconds with not enough data, the measurement gets set to failed. That way the amount of wrong measurements has been reduced a good bit
2. I don't know if this is actually a causation, but I haven't had a reboot in 19hrs on a busy day like today where I usually get a reboot every few hours. This might have been fixed by a bug that was in the old version of background HR, or maybe I messed up the merge when I first merged background HR onto my device (long ago, more towards the beginning of my PineTime journey so I was definitely less experienced and the chances of me having messed up there aren't small)

I'll keep an eye out on 2. and on bugs in general of course.

PS: Now that measurements can fail, the value will be set to 0 and look awkward on the watch face. I solved it like this and I think this might be a good idea going forward (of course, again, the amount of dashes (-) is debatable)

Thinking about it, it would actually make a lot of sense if this updated background HR fixes my reboots:

Most of the reboots I have encountered have been when I am moving. I usually get a lot on the bike, and not so many just sitting at home. Sometimes when I'm sick and don't go out at all, I noticed uptimes of up to multiple days. All of this points to the idea that the reboots have something to do with me moving.
I originally thought that something was up with the accelerometer - of course I did, because the accelerometer is specifically for movement. But now that I thought about the updated background HR more today, maybe that's not the case.

The HR sensor on PineTime is notoriously not very good, if it works at all, when moving. That leads me to believe, that maybe the background HR was responsible for my reboots.
The new version of background HR (this PR) has the fail save function to mark measurements as failed when there hasn't been enough data for 30 seconds.
On the old version, I could imagine me being on the bike, a background measurement gets called and, since I'm moving so much, it can't gather enough data and gets stuck in that measurement loop and eventually crashes.

So maybe the fail save function in this PR has fixed that. Has anybody noticed similar behavior?

PS: Now that measurements can fail, the value will be set to 0 and look awkward on the watch face. I solved it like this and I think this might be a good idea going forward (of course, again, the amount of dashes (-) is debatable)

I'd very much welcome a PR which replaces zero with - everywhere. And TBH we should also refactor it all to expect std::optional<uint8_t> rather than uint8_t so we can discard the hacky zero value altogether

PS: Now that measurements can fail, the value will be set to 0 and look awkward on the watch face. I solved it like this and I think this might be a good idea going forward (of course, again, the amount of dashes (-) is debatable)

I'd very much welcome a PR which replaces zero with - everywhere. And TBH we should also refactor it all to expect std::optional<uint8_t> rather than uint8_t so we can discard the hacky zero value altogether

See: #2342

OK should be good to go now. Will try get InfiniSim PR up soon

@mark9064 InfiniTimeOrg/InfiniSim#180 might serve as a base :)

@JF002 Hoi, ik zou graag even privé met je praten. Heb je een momentje?

Sim PR is up InfiniTimeOrg/InfiniSim#184

Compiles locally
Merge this first, then bump the sim InfiniTime version? (@NeroBurner let me know what works best for you, I don't use the sim too often 😅 )

either make the sim work for both code versions or I'll merge the sim PR after this one is merged

Due to this PR being merged, I built InfiniTime myself from current master (7128fc0) to test it. I enabled background HR from the settings, but I never got results in Gadgetbridge, whatever interval (even continuous) I selected.
Looking at the bottom of the watch, the green led doesn't even light up like it does during manual measurements. Do I need more PRs merged or settings changed to get this to work?

HR needs to be turned enabled for background measurement to happen - do you have it turned on in the heart rate app?

Oh, that's it! Thanks!

It wasn't clear to me that it isn't enabled automatically when the background hr setting is enabled. Perhaps that would be a good improvement? Or at least a warning that it needs to be enabled from the hr app as well?

Glad it's working :)

Maybe a warning would be good? Supporting background measurements with no screen on feels a bit weird - how should we communicate that a heart rate value on screen is not being currently measured?