Increasing confidence in alarm

[medeyko]

Verification

• I searched for similar bug reports and found none was relevant.

What happened?

Awful user experience with 1.9.0 alarm version

What should happen instead?

Alrms should work like in 1.8.0

Reproduction steps

It's not a technical bug, but awful user experiece.

Just set up an alarm in 1.9.0, then sleep hard, and miss the alarm.

More details?

After shifting to 1.9.0 I missed alarms all five times I tried.

I had absolutely no problems with 1.8.0 alarms.

So this limited vibration period introduced in 1.9.0 makes alarm not only unreliable, but completely unusable for hard-sleepers.

I had to fall back to 1.8.0 version.
Probably I will try to learn how to make a custom build, but no doubts I'm not the only hard-sleeper on the Earth.

Version

1.9.0

Companion app

[Riksu9000]

Duplicate of #1086

[Riksu9000]

#1086 (comment)

According to this I may have misunderstood, but are you sure it's not the same? How do you know if it rang or not?

[medeyko]

Unfortunately, I can't be sure that it vibrated. But I all the times when I was already alert at the time of the alarms, it vibrated properly.

I guess, I should do more experiments. Ok, I will do them for about a week, and then will report back with the detailed stats.

[Riksu9000]

Did you ever happen to check how long it had to vibrate until you woke up with 1.8.0 behaviour? What was the longest time?

[medeyko]

I didn't check, as it worked fine, but definitely less than 10 minutes.
I will check this with 1.8.0 as well!

[medeyko]

Preliminary information: it seems that my problem is indeed duplicate, and differences of outcome in case of "sleeping experiments" and "alert experiments" was caused by the distance beween the watch and the smartphone it is paired with.
It alert state they were near, but when I was sleeping, the smartphone was laying in another room, so the bluetooth connection was unstable.

As for the wake time, I registered 5 to 25 seconds, so 60 seconds seem to be too few to confidently alert hard-sleepers.
I would ask to increase it for 300 seconds. Confidence in alarms is very, very, very important. The lack of confidence in alarm makes nervous and harms quiality of sleep...

[Riksu9000]

I'll reopen this as increasing confidence in the alarm.

[medeyko]

Yesteday I turned the bluetooth off (in order to avoid interference with the companion app), set alarm, but didn't wake at time. I will continue experiments.

[JF002]

Awful user experience
but awful user experiece
Just set up an alarm in 1.9.0, then sleep hard, and miss the alarm.
but completely unusable for hard-sleepers

@medeyko May i suggest you be careful with the words you use ? I understand you're frustrated by this potential regression in the Alarm management, but remember that none of the devs are actually paid to put up with angry customers. We are all working on this project on our free-time, and I have to say that reading such formulation is not very pleasant.

That being said, I've seen a couple of users reporting issues with the Alarm, so there's probably something we can improve here. Feel free to provide as many details about the issue.

[medeyko]

@JF002 English is not my native language, so I may miss some nuances, but I don't feel that the wording "awful user experience" is hostile towards devs! I of course value very much the efforts devs put in this firmware. And I don't imagine myself a customer, but a person who worries about the product he loves.

I would explain why I used the wording "awful user experience". It's because the unreliable alarm is indeed an absolutely awful thing for the user experience: it is not kind of problem that you notice at time and can immediately use some work-arounds, including using other tools than PineTime; but the kind of problem that you know of only when it's too late to do anything. If the alarm clock don't wake you and you missed an importand meeting, you drop the alarm clock and buy another. Because the unreliable alarm clock is not an alarm clock at all...

Again, I'm not an upset customer, I will stay with PineTime+InfiniTime no matter what, for its open source nature and respective community. But I worry about the problem I consider a severe one.

[Riksu9000]

In this case I think it would have been best to simply explain the issue without inserting your personal opinion. We all understand that missing an alarm is a big problem. There's no need to clarify that the changes that were recently made by someone were indeed awful in your opinion. Awful is a strong word. Please be careful using it.

[medeyko]

@Riksu9000: Not the change is awful, but it's the problem in terms of user experience that's awful, that was point. I believe the worse class of problems are just security problems. Ok, let "awful" is inappropriate. But the problem is still extremely serious. You write that all understand that. Great!

But then I would expect that such big problems to either be fixed quickly in an emergency release, or if there's no resources for it, the multi-part commit that caused them would to be rolled back quickly temporary in an emergency release, and then its parts reintroduced slowly and carefully, part by part (in order to minimize the time during which the serious problem is exposed to the public, and to discover the exact moment that caused the problem if it is not feasible to test without public's efforts)... Maybe with several special builds for beta-testers who wish to help to find the problem, and I'm eager to be a beta-tester like that.

I see that the problem is knowingly exposed to the public for long (currently 19 days), with no roll-back yet (nor fix). That's why it was not clear for me that all consider this problem big. Your message I'm replying to is a first time when developers indicated that they consider this problem big!

I'm trying to experiment with the alarm, and unfortunately it looks that there may be several different (maybe related) causes (all introduced in 1.9.0), so I can't catch exact reproducible steps yet.

Sorry if I wrote anything wrong again! I don't wish to be unpleasant. I just care for the project.

[Riksu9000]

This specific issue is complicated by #1086. I believe that one is more important to fix first. We don't know exactly what's causing it, and someone's reported that it can even happen with 1.8.0 sometimes, so there's nothing that we can simply revert.

As for this issue, there were people who weren't happy with the alarm ringing forever. If we reverted the change, those people would be unhappy. Considering that we don't have that many reports of this issue, I think for most people a minute of ringing is enough. This is certainly still a problem that needs to be addressed by making the alarm ring again after 5 minutes for example, but here's where the part that we aren't paid comes in. Nobody's forced to do work, so it may take some time until someone decides to work on this.

You can always use an older firmware version until this issue has been resolved.

If you wish to beta test InfiniTime, you can build the firmware from the develop branch and use that, or download the builds automatically generated by GitHub Actions. Note that while it's been generally quite safe, you'll still be doing this at your own risk.

[Avamander]

You can always use an older firmware version until this issue has been resolved.

I would emphasize this. The behavior isn't a bug per se, especially to warrant an emergency release.

[JF002]

@medeyko You are right, we all come from different countries with different cultures and languages, and everyone will interpret some words and formulations differently. For me, those words were strong and suggested judgement and negativity. Anyway, let's not dwell on it, I think we understood each other ;)

The emergency procedure you described is definitely something I would expect from a company selling a product with a major flaw, but we cannot apply it in such a small open source project! Analyzing and fixing a bug takes time. Releasing a new version takes time. Reverting a few commits to release a patch version, while still trying to fix the original bug take a lot of time. All of this might be done at some point, when someone has the time to work on it.
We are a small team of volunteers. We work on something when we feel like it. There's no one waiting "on duty" in case a bug is reported by a user. There's no team of designated beta-testers. Instead, there are users and contributors who are using the firmware, testing PR and branches, improving the code and providing feedback.

So no, we are not ignoring your concerns with the Alarm, but we won't work on it in Emergency mode. As other said, you can still revert to a previous version of the firmware which worked correctly for you until the issue is eventually fixed

[j2g2rp]

I experienced today a problem with alarm. The clock didn't vibrated at all.
The alarm was set to 6:27 AM Mon-Fry.
The interesting thing of this is that clicking on info the popup said that the time to alarm were: 49710 days! 6 hour! 24 minutes! and 14 seconds.
Maybe you could think that the info says 49710 days it is a pretty usefull information. But I find also usefull the 6 hours and 24 minutes because I saw that it didn't worked about 5 minutes after it should work, so If I don't care about how many days left to work the alarm hours and minutes should be near to 23 hours and 55 minutes or so.

Turning off the alarm an on again worked to solve the problem but...

There is any other thing to track this bug?

Regards

[Riksu9000]

@j2g2rp Your issue seems to be similar to this one which will hopefully be fixed in the next release coming shortly #1086

[j2g2rp]

Thanks Riksu9000
I explained a procedure to reproduce the bug there rightnow:
#1086 (comment)