MMS works like SMS in this regard. I know that GNOME Clocks had some support for waking up from suspend being baked, but I’m not sure what its current status is.
IM messages - that’s an outright “no” until we get periodic wake ups to check for things like that.
Can I suspend the device somehow by my own. In the past I used
echo mem | sudo tee /sys/power/state
but this did not worked anymore. run it from the terminal and somehow the device was blocked with display on. I had to reboot it with long press of power button.
How about a workaround possibility: call first to wake up (would this count as multi factor security feature?). Not elegant but if there is no other way. Maybe develop this idea to create a password requirement to establish ssh (script to open port for instance) for some actual 2FA (“dial 3 for ssh”, “dial passcode to enable ssh connections”).
I completely understand the reasons for this, but it isn’t great for a phone that was intended to be Matrix-powered. If I understand right, periodic wake-ups aren’t going to work for catching incoming calls on any VOIP system (Matrix or otherwise). I’m happy to be corrected on this…
Obviously an exciting step forward. Of course I had to try it out. I think I saw one of the posts above answer this, but then someone asked the question again, so I’ll help re-answer. In my experience the only issue was that my morning alarm did not wake up the phone. It just told me later when I got up on my own that I had missed it.
So then I told my phone NO, YOU missed it. And then phone said, “Oh yeah?” And I said, “Yeah.”
But I had woken up anyway, so I still had to go to work.
I don’t know why the suspend needs to be so long. In terms of clock cycles of the CPU, this sounds like an eternity. What matters to save power isn’t the continuous off-duration, but the duty cycle of the on/off periods.
A series of events that need to happen upon wake should be established. Let’s say that a polling of fifty events needs to be checked upon every wake. If each event takes 1mS (1 mili-second) each, then checking 50 events takes 50 mS. That’s one twentyth of one second or 5% of one second of awake time. If the phone stays asleep for ten seconds each time before waking, then the phone is awake for only 0.5% (one half of one percent) of the time in such a duty cycle. So you could wake the phone every 10 seconds and increase the battery by several times over, in the process. You might even be able to do the same if waking up once every one or two seconds to save a lot of power.
Although my example may or may not be accurate, the concept should still apply. At GHz processing speeds, you can wake up, do a lot in a fraction of one second, and then go back to sleep for a majority of one second before waking up again. So why wait several minutes to wake the phone up?
I think i would like to add not sure thats the right topic here but for long battery life you need three things.
device hardware suspend function,
OS suspend function,
application suspend function.
Scenario suspend each app, only keep active the app a user is viewing (basically only keep that desktop alive in which the app is running - on fullscreen in phosh). That isnt happening now or at least not aggressively enough.
OS suspend scenario would be to stop notifications when do not disturb is selected or reduce frequency of querying for notifications when in power save mode, stop all background running app processes etc.
Then scenario discussed here where devices on the phone are selectively powered down or up, or put into powersave mode. e.g. drop frame rate and screen refresh when reading a book and only bump up frame rate when user starts touching the screen etc
Because it an experimental stage, then the suspend config on setting it is for laptop, not for mobile. Of course Purism will perform suspend mode in the best and smart way to L5.
Purism team is constantly adding battery-save in all 3 modes, Active, Inactive and Suspend.
I did longer testing. In 8h (+1min), with all the kill switches in use (phone as idle as possible), using the suspend preview, battery went from 98% to 70%. This gives much more accurate picture of the potential of the suspend feature - huge possibilities compared to current usetime (even if ~2,25%/hour isn’t very efficient - still no optimization yet)! Several times more than the previous estimate based on two hours (although the setup was different too).
Like in previous test, L5 clock alarm did not wake me up, but that’s why we have backup systems. Interestingly, it started to ring immediately when I pushed power button to wake the phone, as the wake-up ring event was still in progress [made me wonder: who woke up who…? ].