Mqtt client on Thread best approach?

[metalgear12]

Our team is building a smart lock for hotels. 

- nRF52840 chip being used

- Thread as the communication protocol
- Pcb will be powered by 4x aa batteries that I expect to last 6 months minimum.

- Want to use Mqtt or nats for the smart locks to send/receive events.

Now in order for our smart lock to get commands to "create new access code" or "unlock door" I will need to receive events that the lock is subscribed to with either mqtt or nats. My question is after the chip is connected to the thread created by a border router with internet access I am under the impression that the smart lock pcb nRF52840 firmware has internet access just as if it had an onboard wifi connection. Is that correct to assume that I can use the mqtt client directly on the node? 

Also what would be the best approach to save battery power? I do expect a lock store the new created access code event within 5-10 seconds of creation. I was reading on SSED and got really confused on how a mqtt subscribed event coming from my broker would be handled when a SSED node is sleeping. Does the border router hold it until the node wakes up? Do I need to program that logic in the border router or is it handled automatically? Or do i put a mqtt broker in the border router that takes in subscribed events from my cloud broker and pushes it to the SSED devices when they wake up? 

If someone could suggest the best solution for a smart lock that needs to be battery efficient and will receive/send events with preferably no more then 5 second latency I would tremendously appreciate it.  

[metalgear12]

Tysm for that info. That is very helpful. I am leaning towards thread. I can easily have parent nodes on each floor and make sure they are within reach of each other and the border router. My main concerns right now are the following:

1. What battery life can we predict for smart lock (assuming the chip is the only power consumption for now) when using 4x aa batteries and say the device gets 3 mqtt events coming in per day and gets woken up to send a mqtt command to cloud broker 10 times a day for things like guest used access code to enter. Just a rough estimate. Trying to understand if thread can get me to 6 months atleast. 

2. For my setup, border router in hotel office main floor, parent router on each floor always on, now should should the end devices (smart locks) use sed ssed? 

3. Should we use nRF52840, nRF5340, or another for my smart locks?

4. We want a minimum of 5 second latency for the end device smart lock to process mqtt events. Does that mean it sets up a sleep schedule to wake up every 5 seconds or is there a way the parent node can wake it up? 

5. Really confused when a thread end device is sleeping, and a event that it is subscribed to gets published on the cloud mqtt broker, will the open thread api automatically handle the parent node storing the network packets (mqtt subscription event incoming)? will the parent node just store it and when the scheduled time for the end device to wake up the parent node pushes any packets it got when it was sleeping? Is this logic all handled for me? At first I was under the impression that I had to program the storing and routing of mqtt subscriber events received when end device was sleeping manually with my own code.

Thanks :) 

[Edvin]

metalgear12 said:

For my setup, border router in hotel office main floor, parent router on each floor always on, now should should the end devices (smart locks) use sed ssed? 

Either should be fine. You will need to test them to see if they meet your current requirements.

metalgear12 said:

3. Should we use nRF52840, nRF5340, or another for my smart locks?

I would say that either should work. What you can do is to try to build the application for the nRF52840, and make sure that there is enough flash to do DFU (if you intend to have it. It is very common in end products these days). A doorlock is not a very demanding application, in terms of ram and flash. The challenge may be to have DFU capabilities, so you may need an external flash chip (like the one on the DKs). Moving over to the nRF53 doesn't really give you more flash, but the network core will handle the network protocol (thread). So you can test whether you can fit the DFU in there before going with nRF52840 + external flash. 

It should be a minor change from running the application on an nRF52840 to running on an nRF5340, so you can experiment with both, if you have one nRF52840dk and one nRF5340dk. 

metalgear12 said:

4. We want a minimum of 5 second latency for the end device smart lock to process mqtt events. Does that mean it sets up a sleep schedule to wake up every 5 seconds or is there a way the parent node can wake it up? 

That is correct. This is why it doesn't really matter how much data and how many times per day you send updates, which you commented on in 1). Of course it matters a bit, but the main part that will affect your current consumption will be how often the SED/SSED will wake up to poll for messages. You say that you want a 5 second latency. This means that you need to wake up at least every 5 seconds. You will need to experiment with the wakeup interval to check the current consumption, and do the calculations. I suggest that you look into trying the nRF Power Profiler, which can very accurately measure the current consumption for your different setups. 

Just for some ballpark numbers, I ran the coap_client sample, built for and running in SED mode. Without any communication configurations, it looks like it is set up to wake up every 3 seconds. This is it's current consumption:

Sending a message to turn on the light on the coap_server draws a bit more:

But as you can see, most of the time it will wake up every 3 seconds, and it draws right under 8µA. If the nRF was the only thing drawing current in your product, that would mean that your 10 000mAh will last a long time. But of course, I guess you will have other components as well, such as motors for locking/unlocking the door.

metalgear12 said:

5. Really confused when a thread end device is sleeping, and a event that it is subscribed to gets published on the cloud mqtt broker, will the open thread api automatically handle the parent node storing the network packets (mqtt subscription event incoming)? will the parent node just store it and when the scheduled time for the end device to wake up the parent node pushes any packets it got when it was sleeping? Is this logic all handled for me? At first I was under the impression that I had to program the storing and routing of mqtt subscriber events received when end device was sleeping manually with my own code.

I may have simplified it a bit. I believe that all messages that are directly intended for the SED (the SED is the receiver address of the message) is stored by the parent. I believe the timeout for publish messages and the poll period of the SEDs will determine whether the message is sent or not. I suggest you play around with the coap client/server sample, and experiment with poll periods, and try sending messages from the server to the client while the client is in MTD mode. 

To build the client sample in MTD/SED mode, use the build command:

west build -b nrf52840dk_nrf52840 -d build_sed -- -DOVERLAY_CONFIG="overlay-mtd.conf"

Or set it up like this in VS Code:

Best regards,

Edvin