FR: reboot resilience

[thiswillbeyourgithub]

Verification

• I searched for similar issues (including closed issues) and found none was relevant.

Introduce the issue

Hi, maybe if we stored the latest state to the permanent storage (alarm time, settings) then a reboot during the night or snooze would be that bad because wd could resume where we left off?

Preferred solution

No response

Version

No response

[cyberneel]

I've thought about this, but the time shifts a little bit when a reboot happens. And we also don't know if the alarm time has passed of if the alarm is for the next day. It requires more planning that made me realize that finding the cause of the reboot and fixing that is better lol.

For now, let me know if you notice a reboot while interacting as those are easier to fix. And any that happen without you interacting, just some time stamp relative to your last interactions might help.

[thiswillbeyourgithub]

For now, let me know if you notice a reboot while interacting as those are easier to fix. And any that happen without you interacting, just some time stamp relative to your last interactions might help.

It rebooted two days in a row. One in prewake and one in natural. Both times it was after snoozing. The first day I think I snoozed twice. The second day once. I have not seen it actually reboot, just noticed it stopped vibrating and the clock was saying 0.

In both cases the watch was in sleep mode.

And we also don't know if the alarm time has passed of if the alarm is for the next day. It requires more planning that made me realize that finding the cause of the reboot and fixing that is better lol

I respectfully disagree, as if the user snoozed and never was the alarm button toggled off (and the battery was not low), then it means it rebooted wrongly and the actual time is probably a bit after the latest snooze and importantly the alarm should still be on after reboot.

I think I understand where you're coming from but given that it's an alarm clock app we can actually warrant the need for a fail-safe as people can miss important things if the alarm fails. And importantly, if the watch reboots, it might be because there's a bug in your code, but it also might be because of old hardware and quality issues and lack of consistency in the manufacturing process. So I think there are good reasons to really think about whether we don't want a fail-safe. That's of course if you manage to do that in just a few lines of code given the memory constraints!

What do you think?

edit :forgot to mention my watch is still in v8 i think. Should I flash something else? Also it rebooted the last two days but I think all the days befofe but I have not been paying too much attention so didn't report

[cyberneel]

@thiswillbeyourgithub Thanks for the feedback, from my experience the alarm is actually on when reboot. The problem is the time shift, which as you said I could likely tackle by keeping track of the snooze. I agree with the points on the importance of the fail-safe since I guess the watch could also reboot from other things.

I'll look I to it more. I've been working on the SleepDataService over ble that allows sending the sleep data to a companion app.

There is a newer firmware with some QOL stuff and suggestions I received, I'll put that up later today.

[thiswillbeyourgithub]

from my experience the alarm is actually on when reboot

For me too but not always

[thiswillbeyourgithub]

This morning it rebooted too. The alarm was set at 8am. I snoozed and it appears to have rebooted (while keeping the time after boot) some seconds before 8:03. I conclude that the reboot might happen when a snooze ends/when the alarm starts. Note that no vibration happens at that exact time.

Edit: this was still on v8