Hey Mohamed, > > I am using a Quectel EC21 modem, connected to an imx6ul soc via usb (UART is > also available), everything works fine and I have connectivity without issues. > > So my usecase is putting both the cpu and the modem, and I am able to do > that, but the wakeup should be from a remote MQTT message coming from my > server which will wakeup the modem first, that in turn wakeup the cpu using > the RI pin. >
Ok. > I have played around with this and it is only possible if I use the modem's > MQTT stack, as it will maintain the TCP connection even in sleep mode. I am > configuring the MQTT endpoint using AT commands (through mmcli --commands). > This makes sense. > The problem is that I am not able to receive the messages when subscribing to > a topic, even though I know the message arrived (I can see the raw data when > putting modemmanager in Debug mode). > > So my question is, is it possible to receive the MQTT URCs (+QMTRECV for > example) over DBUS so that my application could handle them after wakeup, and > if not what path should I follow ? So the MQTT notifications are reported via AT URCs to the host. You could extend one ModemManager interface to expose a new signal that would emit the contents of the received URC, and then you would need to modify the quectel plugin to match the +QMTRECV URC with a custom regex. An example of this would be e.g. the processing of the ^MODE URCs in the Huawei plugin, see how the "mode_regex" variable is setup and how the URC contents are processed in the "huawei_mode_changed()" callback. Once the contents are processed, the plugin calls the mm_iface_modem_update_access_technologies() method, that ends up updating a DBus property with mm_gdbus_modem_set_access_technologies(). > > Note: I tried probing the USB AT interface for incoming URCs but I wasn't > able to receive them, probably because modemmanager is concurrently using it > as well ? Yes, you should not use a TTY port that is in use by ModemManager. -- Aleksander
