Hi Frank,
That is the
exact approach I have used successfully with another mode of
operation on these devices called PSM (Power Save Mode).
Unlike eDRX, PSM is used when the device doesn’t need to be
reachable at a given interval. In this mode of operation,
the device internally decides when to connect to the broker
based on some event. That event could be from a periodic
timer expiration or parameter change.
Waking up and
connecting to the broker to check for or send a message
consumes a lot more power than for the device to wake up and
quickly check if the network is attempting to communicate
with it because it has a pending message to deliver to it.
I thought about
using another application to send a page to the device when
a message on the broker is pending for it, but I was hoping
for a cleaner approach.
John
Hello John,
It's been a few years since I've deployed a cell modem, and I
hadn't heard of eDRX. But it sounds great; much better than
having to manually power the modem up and down each cycle
through an external supply.
Your scenario, however, sounds like a textbook case for using
persistent MQTT sessions. The first time your embedded system
powers up, do the following:
-
Connect with the "clean sessions" flag set to false, and be
sure to use a unique Client ID string for each device. (I
typically use a combination of device type and serial
number). It's also handy to register an LWT message when
you connect.
-
Then register the topics that you want to monitor.
-
Disconnect from the broker.
-
Let the modem power down
When the modem powers back up ("enters eDRX"):
-
Reconnect with the same Client ID and clean_session=false.
This time, you don't need to re-register the topics.
-
The broker will have kept all the messages destined to your
device topics and will send them to you now.
-
Publish any of the messages that you want to send now. (Some
clients will cache messages while you're off-line and
transmit them automatically now).
-
Disconnect from the broker.
-
Let the modem
The broker
will treat your device as having a virtual session across
actual connects and disconnects, and manage the traffic for
you. In this way, your PC client can send messages to the
device at any time, even when it's disconnected, and the
server will hold onto it until the next connection.
This is exactly what MQTT was designed to do and can make your
life much easier.
The downside, obviously, it the additional overhead and
latency of sending connect and disconnect packets each time,
but with LTE modems, this isn't usually a big problem. With
something like a satellite modem, this is more problematic as
the turnaround time is huge.
An additional downside is that you can fill the server with a
lot of data if you have devices that go off-line (break down)
a lot. But MQTT5 has some features to deal with that like
session timeouts ("Expiry").
Give it a try and see if you can live with the additional
overhead. If so, It'll be much easier in the long run.
Frank
On 2/23/19 5:55 AM, john rubis wrote:
Hi,
I have been experimenting with eDRX on a
CAT M1 LTE modem that is connecting to a Mosquitto MQTT
Broker. For those of you that are not familiar with eDRX,
it’s a power saving feature available on newer low power,
low data rate LTE modems. It allows the normal “check-in”
time with the cellular network to be adjusted from around 1
second to several thousand. By increasing the time between
check-ins, power is conserved. The tradeoff is that between
check-ins, the device is not reachable.
My embedded test application is pretty
simple, it connects to the broker, subscribes to a topic and
then enters eDRX mode. The application doesn’t disconnect
from the broker once it has initially connected.
Periodically at the set eDRX interval, the device wakes up
and checks for any MQTT messages. It will also wake up and
send a KA if needed at the KA interval which is 3600
seconds.
On the other side, I have a simple PC
based client that can post messages to the topic the
embedded device is subscribed to. The test procedure is to
wait for the device to enter eDRX and then post a message to
be delivered to the device.
My initial testing went well up to the
point I set the eDRX time to 1310 seconds. At that point, if
I sent a message to the device while it wasn’t reachable, I
noticed Mosquitto would report a socket error and disconnect
around 1000 seconds. I thought maybe the OS was closing the
socket for inactivity, but that timeout is 2 hours. So some
error handling in Mosquitto must be timing out and giving up
at 1000 seconds. If I do not attempt to send a message to
the device it stays connected with no socket errors and at
the KA interval, I see a KA sequence between the broker and
the device.
It's possible the way I am attempting to
use eDRX with MQTT is flawed, but I don't see another way.
Thanks,
John
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/mosquitto-dev
