Handling received SMS
colin.helliwell at ln-systems.com
Mon Feb 13 11:46:13 UTC 2017
> On 13 February 2017 at 09:48 Aleksander Morgado <aleksander at aleksander.es> wrote:
> On Mon, Feb 13, 2017 at 9:13 AM, <colin.helliwell at ln-systems.com> wrote:
> > All I'm seeing in the logs is "+CIEV: message,1".
> > Checking back through the logs for unsolicited event setups, I also see
> > [src/mm-broadband-modem.c:5888]
> > set_messaging_unsolicited_events_handlers(): (ttyMux0) Setting messaging
> > unsolicited events handlers
> > [src/mm-port-serial.c:1347] _close_internal(): (ttyMux0) device open count
> > is 1 (close)
> > [src/mm-iface-modem-messaging.c:867] enable_unsolicited_events_ready():
> > Couldn't enable unsolicited events: 'SMS settings don't accept [2,1]
> > '
> > That inner error message seems to originate in the Cinterion plugin's
> > messaging_enable_unsolicited_events (). From what I can make out, that
> > function is looking for a supported mode in the response to "AT+CNMI=?".
> > Doing this from the command line gives the response " +CNMI:
> > (0-3),(0,1),(0,2,3),(0,2),(1) ". Furthermore a "AT+CNMI=2" also from the
> > command line - which I think the plugin would have otherwise tried to do
> > if it had found the mode - does give an OK response.
> The +CNMI=? parser didn't expect the "range" format given for the
> field. I've fixed that in git master now.
Thanks, I'll try to get that patched into my 1.6.4 version that I'm using currently.
> > But I think I need to switch back to the Generic plugin, for simplicity,
> > and see how that behaves. I have though already seen some
> > incompatibilities which I'll need to address - and these may be related to
> > this problem. E.g. a parameter used for 'AT+CMER=3,0,0,1 ; and also param
> > value problems with 'AT+CNMI=2,1,2,1,0'.
I've fixed up both of these commands, and now see the new SMS being read. I'm sure if one/other/both fixes are needed - but I'll try next. But whilst the fixed parsing should fix the plugin's behaviour, I'm still going to see the 'AT+CNMI=2,1,2,1,0' which is sent by modem_messaging_enable_unsolicited_events() - hopefully not a problem if the plugin then enables them ok?
The Cinterion plugin does address the CMER variation itself, although that command doesn't seem to be supported at all on the EHS5 (according to docs)! My dev board has the BGS2 - should be getting 'real' prototype boards this week with both flavours, so I can check for any other command differences.
> > In the case of the latter, the
> > code looks like it is written to have 3 forms of this command to try -
> > cnmi_sequence - but although my modem fails the first " +CMS ERROR: 500
> > ", the other two aren't then tried instead?
> Looks like the retry is only done if "not supported" errors, not in
> "unknown" errors..
> Dan, should we remove that condition and retry on any kind of error?
> The logic was introduced in 1d9164ec90788d1be134482ff88c501e3c5d623c.
More information about the ModemManager-devel