Wait for SMS messages

[Dan Williams]

On Thu, 2025-01-30 at 23:46 +0000, Brendan Simon wrote:
> 
> IND.T Classification: Public
> 
> 
> 
> 
> From: Dan Williams <dan at ioncontrol.co>
> 
> 
> 
> Sent: Thursday, 30 January 2025 3:39 AM
> 
> On Tue, 2025-01-28 at 12:05 +0000, Brendan Simon wrote:
> > 
> > What's the best way to monitor and wait for SMS messages for
> > processing?
> > I'm using a Debian based system and python3.
> > I was thinking of something involving systemd and/or a python
> > package
> > such asdbus_next.
> 
> With Python we'd typically use the bundled GObject introspection data
> to directly work with libmm-glib. There are some examples in MM git:
> 
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tree/main/examples?ref_type=heads
> 
> I added an SMS watcher example here:
> 
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1284
> 
> Hopefully that's easy enough to follow, all questions welcome.
> 
> It does require a bit of D-Bus knowledge to fully understand the
> flow,
> but even without that you just plug your own code into the
> SmsWatcher's
> show() method and that'll run for any "new" SMS from any modem. I say
> "new" in quotes because it'll also print out any messages in the
> modem
> at the time it's run, then wait for new ones from the network or
> local
> addition.
> 
> 
> I tried the SMS watcher example.
> It seems to work mostly, however in the code snippet below, the new
> message does not appear in the list from list_sysnc(), and therefore
> the sms object is never added to self.messages.
> Is this expected or is there something else missing?

Are you able to post the ModemManager-side --debug output of receiving
the message?

I did test the code out (QMI-based Huawei LTE device) and it works
here, but that doesn't at all mean you're wrong about it failing for
you.

> What is the purpose of SmsWatcher?  Why do I need to "watch" SMS
> messages once we have processed them with MessagingWatcher?

It's for multi-part messages, where the parts are received at different
times and are technically different SMS messages, but really a single
big SMS.

When MM sees a piece of a multipart message, it'll create the SMS
object to track all the pieces and then change the SMS's 'State'
property to indicate when all parts have been received.

The partial SMS still needs to be exposed to clients somehow just in
case it never becomes complete, since the message can still take up
storage.

That all said, we could perhaps make clients easier to write by adding
convenience methods so you don't have to watch the SMS objects
themselves as much. It's also silly that we have to list all SMS again
just to get the one we want.

> Is it for things like handling message deletion or other events?
> 
> 
> ```python
>     def on_sms_added(self, messaging, path, received):
>         for sms in self.iface.list_sync():
>             if sms.get_path() == path:
>                 #>>> NEVER GETS HERE AS THE NEW MESSAGE DOES NOT
> APPEAR IN THE RETURNED LIST OF MESSAGES !!!

Yeah, this seems like an issue; any SMS for which the "Added" signal is
sent by definition should be in the explicitly requested SMS list. The
ModemManager --debug output may be able to help with that.

The other thing you should do is run:

sudo dbus-monitor --system "type='signal',sender='org.freedesktop.ModemManager'"

before sendind the new SMS and include that output along with the MM
debug output (remove private info like phone numbers of course!). That
shows us exactly what MM is doing, as opposed to what the client side
(sms-watch-python) is doing and can help us narrow down the issue.

Thanks,
Dan

>                 # Watch this SMS
>                 self.messages[sms.get_path()] = SmsWatcher(sms)
> ```
> 
>