Entering standby on demand

[mcguirepr89]

I have done my best to create a feature that would allow me to put the watch in standby mode, but I find that I'm unable to get the functionality to meet my needs.

I've tried using watch_enter_sleep_mode(), which seems to partially do what I need, but after calling that directly, I'm unable to wake the watch with the usual ALARM button press. In addition to that shortcoming, the watch seems to exit the sleep mode at the top of the next minute. (It seems I would essentially need to mimic the static _sleep_mode_app_loop() that movement.c uses within its scope, but that is where things get pretty complicated because it's also handling background tasks for the other faces, I think?)

As another recourse, I tried creating a sleeping boolean as part of my face's context, checking for that prior to the event switch in my face's main loop, and then forcing the event.event_type = EVENT_LOW_ENERGY_UPDATE, but this isn't really what I want either.

If anyone can help me with getting this functionality into my watch face, I would really appreciate the insight! Thanks in advance to all who help out

[joeycastillo]

This sounds like a function that I should write into Movement. Luckily I'm working on the Movement 2.0 refactor today; it seems like a simple thing to add.

Will keep you posted!

[mcguirepr89]

Thanks for the swift and exciting response! I certainly look forward to it. I'm going to open one more discussion about an addition that I've put together in my changes with movement just to share the ideas and use cases. Stay tuned :)

[joeycastillo]

I went ahead and added this function here. Second Movement isn't quite ready for PR's, but it is good for folks to start to review it.

Right now requesting sleep causes Movement to go to sleep after one tick; I think we can shorten that to an immediate sleep by changing that number from 1 to 0, but I didn't have time to test it extensively, so that's what I was able to put in for now!

[mcguirepr89]

This gives me exactly what I had hoped for -- I don't see a difference when using 1 or 0 -- it seems like both are still waiting for the next tick, but I will flash two boards, one with le_mode_ticks set to 0 and one set to 1 and will see if I notice any differences. I'm afraid I won't be much help when evaluating the code at any kind of granular level, but am always happy to test and provide the empirical feedback :)

Thanks, again!

[mcguirepr89]

After getting both watches flashed with their respective le_mode_ticks, I can report that I have noticed what I suspect is the race condition you mention in the #FIXME -- the watch that has le_mode_ticks set to 0 in movement_request_sleep() sometimes goes to sleep and does not seem to return to the loop.

I'm using the new function in this code here. What I see in the suspected race condition is that the face gets stuck displaying "sleep" from the EVENT_ALARM_REALLY_LONG_PRESS event.

[mcguirepr89]

A really strange thing has happened after the watch slept for a few days (unsure how many), and I suspect it has something to do with using this new function:

Sensor-Watch-Glitch.mp4

If you have any ideas on whether you think this is related and/or what might be going on, I'd love your insight