Feature: Push messaging via gotify (or similar)

[prurigro]

The ability to have the modem listen for network-based messages and wake the pinephone up so it can alert the person carrying it would be extremely useful. I realize there are a bunch of potential routes that might make the most sense, but I thought it would be good to at least get a conversation started.

I currently have https://github.com/ztpnk/gotify-dunst running on my ppp. It's a lightweight script that runs in the background and listens for new notifications from a connected gotify server. How feasible would it be to get something similar running on the modem? If it could wake the phone up when it detects a message, the phone could then connect to the internet, receive the same message and alert the user before sleeping again.

Thoughts?

[Saddamus]

Why there is even no comment on such a key feature question ? If Pinephone has to be considered as a smartphone, it should be online which is impossible without push notifications or (like now) fast battery draining.

[Biktorgj]

Because:

1. It's been asked already
2. I'm already working on trying to get internal userspace network running and things are never as simple as they might seem
3. Bridged mode with call support / routed mode aren't compatible settings neither in the modem or ModemManager so if it's even possible to pull that off it's going to be hacks all the way
4. There are plenty of other important things to do, like getting VoLTE working for everyone, fixing bugs and finishing WIP features
5. It can be mitigated with a systemd timer in the host for periodic wakeups. It's not push, but won't cost nearly as much power wise and can be made to resume, wait 20 seconds and suspend again while keeping the screen off

Even if I managed to get the modem to sniff out the settings provided by modemmanager and lie to the host about how it is connecting, got routed mode working while keeping QMI support in place etc, the modem is only able to wakeup the host by triggering a GPIO. So the only thing it could do is trigger a resume on the host simulating a call/message which would turn on the screen for every message received, wasting a ton of battery, but wouldn't even be able to tell it to sync and sleep again, so then the Pinephone would wait for minutes at full power with screen on until it's time to sleep again. And that without accounting for the energy consumption increase in the modem for keeping active connections, more services running etc.

Neither an Android phone or an iPhone use suspend. They enter power saving mode in all the devices they have to waste as little battery as possible. They also suspend their apps and only allow a handful of proxy services in a queue to gather updates. The proper way of fixing this is to fix runtime suspend in all the drivers in the kernel, so devices can shutdown when not in use even if the display is on, everything else is just a workaround (even if I think a workaround is still better than nothing).

[Saddamus]

Thank you for your answer. I agree to your conclusion. With this kind of limitation, the only right solution would be to make a "mobile" linux kernel working like Android. Periodic wake-up does not resolve the problem, because you can not handle VoIP calls this way. Also imagine that you have push notifications from monitoring system and you get a message that key services are down 15 minutes after message was pushed :) I think this question should be rised across projects and answered if and who should put this solution to their roadmap. At the moment it doesn't look promising, especially that linux phone was already under comercial support from Canonical with no achievements in this matter.

[Biktorgj]

...At the moment it doesn't look promising, especially that linux phone was already under comercial support from Canonical with no achievements in this matter.

Distros might need some work to optimize stuf, but I think the more pressing problem right now is with the drivers that give specific support to that specific SoC with that specific configuration. To give a simple example, let's take the eMMC controller driver in the PinePhone Pro.

Until recently, it didn't support runtime suspend. That meant that as long as the phone was not in a suspended state, the emmc controller wouldn't sleep, even if it wasn't being used in anything. Support for this was added not long ago, reducing quite a bit the power consumption (https://github.com/megous/linux/blob/orange-pi-6.0/drivers/mmc/host/sdhci-of-arasan.c)

But the controller is only used by some specific vendors, so while this solution fixes an issue in the Pro, it wouldn't matter in the case of a Qualcomm SoC for example (or the original Pinephone).

Downstream kernels are usually "optimized" for the specific SoC they were forked for, they tweak their drivers to try to get everything correclty running for that SoC, but they don't care so much about breaking compatibility for everything else which ends up in this

Fixing that involves going through all those hacks and patches and refactoring them to be able to mainline them, but that takes time...

As for the apps and distros, the more important thing missing in my opinion is a way to tell applications to limit themselves when not in use, while keeping them working (for example, a music app or an email client should be able to keep playing or fetching messages even if the display is off, but you don't want your map to keep using GPS while it's not in 'navigation' mode and it's in the background), but fixing that, I'm afraid, is up to application developers themselves

[prurigro]

This is all really interesting. Thanks for the time and thought you've put into the larger problem space!

I agree that we're probably not going to see people writing desktop apps that include low power states while not in active use, which is why some sort of single-point notification system that runs in the background seemed ideal. The fact that it would both involve a collection of hacks and create significant battery drain for each message received though makes that solution much less attractive for now, and if we get to a point where it is attractive it sounds like it could be run on the main SoC since we'd have a proper power saving mode.

I suppose in the mean time, important messages could be routed through a server via sms and it would avoid the need for any changes. I'd originally discounted the idea because of how expensive 50-100 notifications per day was looking, but it sounds like 50-100 notifications would leave the battery dead either way, and ~5-10 important ones aren't going to be a big deal.

So that said, if anyone ends up here looking for a short-term solution, https://voip.ms/ offers an API that you can use to script the sending of sms messages, and here's a simple script that can be used to do that + check the account balance (replace ##STUFF## with appropriate values):

#!/usr/bin/env python3

# Send SMS and retrieve account balance with the voip.ms API
#
# Configure the API here: https://voip.ms/m/api.php
#
# Dependency: pip install --user voipms

import sys
from voipms import VoipMs

client = VoipMs('##USERNAME##', '##APIKEY##')

DID = ##YOURDIDNUMBER##

if len(sys.argv) >= 2:
    if sys.argv[1] == 'send-sms':
        if len(sys.argv) >= 4:
            client.dids.send.sms(DID, int(sys.argv[2]), sys.argv[3])
        else:
            print('Run with a phone number and message as arguments')
    elif sys.argv[1] == 'get-balance':
        print('{0}'.format(client.general.get.balance(advanced=False)))
    else:
        print('Invalid command')
else:
    print('Commands:')
    print('  send-sms {number} {message}')
    print('  get-balance')