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
From: Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx>
Sent: Saturday, February 23, 2019 9:33 AM
To: General development discussions for the mosquitto project <mosquitto-dev@xxxxxxxxxxx>; john rubis <john.rubis@xxxxxxxxxxx>
Subject: Re: [mosquitto-dev] eDRX and MQTT
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
