Just for another data point: I had the same issue. I'm not sure I quite understand the issue - running AT+CMGD=? after sending myself some texts seems to show that there aren't any saved on the modem - so is ModemManager deleting them sometimes?
I have been playing with this. It seems to me that the only SMS that build up and hang around on the modem are:
SMS I send. These stick around until I reboot the phone.
MMS notification SMS. These do not show up in Chatty because it does not yet support MMS. Instead these simply build up on the modem until I manually delete them with mmcli.
Full disclosure: I have not experienced this bug. I simply regularly check my modem for a build up of SMS so that I can manually download my MMS using curl. Perhaps if I didn't manually delete the SMS after downloading the MMS, this bug would manifest itself on my phone.
pachumicchu was able to send an MMS through mmsd via modem manager! It also seems to handle recieving MMS with purple-mm-sms, but work is needed to integrate it with Chatty and upstream puple-mm-sms.
So it looks like MMS support is progressing, and will eventually work with chatty (Phosh).
For Plasma Mobile, ofono is being used instead of modemmanager. I'm not sure if the problem of unhandled MMS notifications filling up the cache exists for plamo as well, according to this, in theory telepathy-ofono should handle MMS?
@blendergeek wrote:
SMS I send. These stick around until I reboot the phone.
That seems like a bug in either purple-mm-sms or modem manager. I suggest to try to pin it down to either of those and report it upstream.
Back to the original issue of the SMS cache getting full without the user noticing. I wonder if we could implement a notification, maybe a daemon that checks every few minutes if the SMS cache is full, and if it is, displays a notification to the user with a wiki link where they can read more about that (and learn how to flush their cache).
I was having text issues as well. I could send texts but was not able to receive any. Texts I would send from myself would also not come show up as being received. This issue persisted between phone restarts. I installed minicom and ran minicom -D /dev/ttyUSB2 to talk to the modem. I then echoed the terminal ctrl-a e and ran the AT+CMGD=0,4 command and that didn't seem to help until I rebooted the modem with AT+CFUN=1,1 After the reboot I was able to receive texts from myself as an initial test. I'm not sure how to replicate this issue.
I've been using this regulary as temporary way of getting away with the problem. Unfortunately, you have to redo this after a month or even less if you actually use sms on daily basis. This only purges modem chache but does not prevent it from getting full again.
I'm on edge with phosh and I still experience this. @chastabor solution fixes it for some time like @Malmik said.
It's really problematic if you think about pinephone as a daily driver.
Do you think we should point it on wiki?
How about writing a simple script for newbies or temporary fix like cron weekly job?
btw, how other pinephone distros copes with it, maybe we can ask them?
How about writing a simple script for newbies or temporary fix like cron weekly job?
Yes, adding the command as one-liner to the wiki would be useful. I'd rather not do the cron job, my understanding is that it may lead to deleting notifications that ModemManager currently isn't able to parse (e.g. MMS?).
btw, how other pinephone distros copes with it, maybe we can ask them?
Collaborating on such issues is always a good idea.
So I thought I would follow up with my experience with not receiving SMS text issue and fixes. About a week ago I noticed that I stopped receiving SMS texts again, but the clear the cache solution didn't work. I attempted to clear it with and without restarting the modem to no avail. I found mobian1 issue 215 talking about chatty issues. It described how to view the SMS list with the mmcli command @blendergeek mentioned above:
#NOTE: Modem number increments each sleep; so find it's number with mmcli list modems argument.mmcli --list-modems /org/freedesktop/ModemManager1/Modem/4 [QUALCOMM INCORPORATED] QUECTEL Mobile Broadband Module#NOTE: Use modem number to get SMS listmmcli --modem 4 --messaging-list-sms -v[20 Feb 2021, 15:54:13] [Debug] ModemManager process found at ':1.2'[20 Feb 2021, 15:54:13] [Debug] Assuming '4' is the modem index[20 Feb 2021, 15:54:13] [Debug] Modem found at '/org/freedesktop/ModemManager1/Modem/4'[20 Feb 2021, 15:54:13] [Debug] Synchronously listing SMS messages... /org/freedesktop/ModemManager1/SMS/52 (sent) /org/freedesktop/ModemManager1/SMS/51 (received) /org/freedesktop/ModemManager1/SMS/50 (received) ... more 44 to 49 more received messages /org/freedesktop/ModemManager1/SMS/43 (received) /org/freedesktop/ModemManager1/SMS/42 (received)
So I went ahead and deleted the items listed in the SMS list from 42 on up to 52 with the mmcli command as follows:
mmcli -m 4 --messaging-delete-sms=42successfully deleted SMS from modem ... continued deleting 43-51mmcli -m 4 --messaging-delete-sms=52successfully deleted SMS from modemmmcli --modem 4 --messaging-list-smsNo sms messages were found
As soon as text message 52 (sent) message was deleted I started receiving text messages again. This week I'm still receiving texts, yet I'm seeing the SMS list grow again and don't know if that is going to become another issue. Following is current SMS list for today and text messages still work:
mmcli --list-modems /org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] QUECTEL Mobile Broadband Modulemmcli --modem 0 --messaging-list-sms -v[28 Feb 2021, 12:48:35] [Debug] ModemManager process found at ':1.2'[28 Feb 2021, 12:48:35] [Debug] Assuming '0' is the modem index[28 Feb 2021, 12:48:35] [Debug] Modem found at '/org/freedesktop/ModemManager1/Modem/0'[28 Feb 2021, 12:48:35] [Debug] Synchronously listing SMS messages... /org/freedesktop/ModemManager1/SMS/5 (received) /org/freedesktop/ModemManager1/SMS/4 (receiving) /org/freedesktop/ModemManager1/SMS/3 (received) /org/freedesktop/ModemManager1/SMS/2 (receiving) /org/freedesktop/ModemManager1/SMS/1 (received) /org/freedesktop/ModemManager1/SMS/0 (received)
Hope not to offend anyone if they already know this, however, I thought I would share another way to send the AT commands using atinout I found out about this past week to avoid having to use minicom, which started giving me errors with screen size. So if some people coming to this issue are having problems using minicom like I am they can do the following:
# NOTE: clear cacheecho 'AT+CMGD=0,4' | atinout - /dev/EG25.MODEM -OK# NOTE: Restarting modem may be required for setting to take effect.echo 'AT+CFUN=1,1' | atinout - /dev/EG25.MODEM -OK
I'm not expert but this issue is connected with ModemManager. I'm curious how does it behave with ofono? Has anyone tried it e.g. with plasma mobile? How does it behave?
I'm currently on mobian, mainly because of its stability (pinephone is my daily driver). However after three months of using phosh, I still cannot adapt to this UI and I want to switch to plasma (which uses ofono), for now only pmOS with plasma + FDE seems to me reliable in case of being up to date, stability, security and being OSS (mobian doesn't support plasma, openSUSE FDE, Manjaro and Arch are pragmatic distros etc...).
So If you think it may be helpful or become workaround I could test pmOS with plasma for couple weeks.
Thanks! :) Do you think we could also add temporary solutions to save newcomers time, or pin it somehow on gitlab? I'm also not sure if the SMS section on wiki should be Working or Partially... This is serious issue which precludes pinephone being daily driver. But I may be wrong. You decide ;)
I still have a similar issue on edge.
Previously I was able to receive sms but currently nothing gets through, including self addressed messages.
mmcli does not list any sms messages on the modem. I tried to debug the issue with at commands, but am at a loss there without reading the modems documentation.
When I last had this issue, switching to plasma mobile seemingly unclogged something and a lot of sms came through at once, so I guess ofono does something different from modemmanager that somehow alleviates the problem.
What I do find odd is that the modems storage locations for sms are all set to ME (mobile equipment). Can somebody shed some light on why this is?
I've had a cursory read of ModemManager sources and ofono sources.
From what I saw, both are complicated beasts and ofono seems to be full of vendor-specific workarounds and tweaks (most seem to follow the specs, but some just don't).
Overall ofono seems to be very pragmatic.
I still do not know what exactly causes my problems, but I have a hunch it might be that the modem's caches are empty BUT the carrier expects some acknowledgement of the already received sms and holds back any further messages until it receives that acknowledgement (which never arrives).
I am on edge and I use the master build of Chatty.
For months I did not have this problem at all. But, around the 1st of the year, this problem came back. Now, I often go days with no messages coming through and when I check my modem SMS cache it is either empty or there is just one message stuck in the "RECEIVING" state. If I delete that one message and reboot my phone, I will get one or two messages to come through and then it will go back to no messages coming through again (usually with a message stuck in the "RECEIVING" state).
Sending sms with spacebar somehow alleviates the problem. Sending sms with chatty makes it reappear.
BUT spacebar leaves the sent sms in the modems storage for some reason.
Also not all sms sent with spacebar come through either. I have not yet tested if it just ignores some of the messages because receiver, sender and timestamp match. (will have to use a second phone for more tests)
I think it might have to do with delivery reports.
If I read the documentation correctly, then this command sets the modem to route messages directly to the phone without buffering indications of new messages. (and I still do not know where this buffer of indications is).
My guess is that switching modes simply clears some buffer which was previously full.
After a message has been received (not sure if before), the mode can be reset to it's default:
AT+CNMI=2,1,0,0,0
I am pretty sure that the clogged messages get dropped using this workaround but at least it allows new messages to arrive.