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.  

[Edvin]

metalgear12 said:

Is that part of the thread protocol and happens automatically or do I need custom programming something like a mqtt broker on the parent node to hold all the mqtt events that came in while the device was sleeping?

This is part of the Thread protocol, regardless of whether you use MQTT or something else.

metalgear12 said:

2. In a hotel with 40-100 locks do you guys think thread, ble, of simply wifi would be the best approach? I simply want a device that pub/sub mqtt with 6 month battery life on 4x aa batteries. 

I must admit I am not yet very familiar with the WiFi, so for more details, please create a new ticket asking for details regarding WiFi and current consumption. As for Thread, Zigbee and Bluetooth Mesh, the current consumption is quite similar, because they all require the radio 100% of the time (in RX whenever not transmitting). All of them have their own low power nodes, such as SED/SSED in openthread. And common for all the low power nodes is that they need a parent node (or "Friend node", in Bluetooth Mesh) that needs to be a "full node" (Radio in RX when not transmitting), while maintaining a low power connection to the low power node. The amount of low power nodes you can attach to a single parent/friend node depends on network parameters in your low power nodes, but is usually limited by the amount of RAM in the parent node. 

Also, low power nodes don't extend the physical range of your network. Only parent nodes do. If you are using some sort of smart light bulbs that are attached to the same network, these will typically act as parent nodes for low power devices, since these are mains powered. If you don't have any other devices in the network, you would need to set up nodes on each floor with "normal" nodes that can act as parents for the low power nodes. 

One option, that is even more low power would be to use Bluetooth low energy connections. This way, your devices may advertise all times (a lot more power efficient than keeping the radio on in RX mode), and then have gateway nodes that scan for these, and connect to them if they have any updates for them, such as a new combination for the lock, and then disconnect. But this would also require you to have "connection/gateway nodes" on every floor, instead of a parent node, so I guess it is quite similar.

Best regards,

Edvin

[metalgear12]

Thank you for that great response. I dont mind using ble but my ultimate question is what will be best for a hotel with multiple floors and many locks on each floor? Will BLE be able to mesh incase the ble gateway is not exactly nearby? Also will BLE be as reliable as thread? I think I read somewhere thread is more reliable. My big thing is I will have clients throughout the country and have no boots on the ground. It is very important for us that our communication is very robust and reliable and we are willing to do whatever it takes to achieve that.

[Edvin]

Like in Thread you can have Acking on messages in BLE Mesh. However Acking doesn't really make sense in a one-to-many broadcast message, because an Ack will mean that "at least one of the devices have acked your message", but not necessarily all. But in a unicast (message intended for a specific receiver), Acking will make sense. 

Regardless of what you choose, you must remember that these low power nodes that are not connected to a plug in the wall (which I assume your doorlocks are not). they will not be able to relay messages down to your central unit. You need network devices spread over your floors and corridors that are in radio reach for eachother. 

Figure from this guide:

If your door locks low power nodes, they will be end devices. Although this figure is specific for openthread, the same goes for both Zigbee and Mesh. The light blue nodes will not be able to communicate with anyone but their parent. And the parent is not low power (everything is relative, but it will keep it's radio at all times, but the low power nodes will only use the radio in short bursts). 

So you need to spread out the parent nodes so that all the end devices are within reach of one.

In a network like this, with few routers and many children, I wouldn't say that Bluetooth Mesh or Thread is more reliable. They can both cope with retransmissions and Acknowledgements, so really, it is up to you. 

metalgear12 said:

Also will BLE be as reliable as thread?

Assuming you are talking about Bluetooth Mesh here. If you are talking about Bluetooth Low Energy (not Mesh), then it is a different story. BLE advertising and scanning can work as well. In that case, you would need to change out the light blue nodes with advertising devices, and the routers with devices that can talk to your central unit in one way or another. The advantage here is that there is no limit to how many locks the router can handle, because they are not in a connection by default. Whenever the router has received an update from your central unit, it will start scanning, looking for a particular lock. When it has found it and connected to it, it can send the update (over an encrypted connection), and disconnect. 

BLE itself will not mesh. In that case you would need to use something else to reach from the ground floor to the top floor. This can be any of the network protocols that we have discussed. 

I am sorry that my answers are a bit vague, but I try to communicate all the pro's and con's that I can think of. I guess the takeaway is that whatever solution you go with sounds like it should work, but be aware that you need some devices that are not SEDs. Routers or Bluetooth Mesh devices will use the radio 100% of the time. The radio itself will use this amount of power: https://infocenter.nordicsemi.com/topic/ps_nrf52840/radio.html?cp=5_0_0_5_19_14_2#unique_684783103

I am no HW expert, but e.g. 10mA on the routers with 4xAA batteries translates to roughly 1000h (2500mAh per AA battery = 10 000mAH, which is 1000h under ideal conditions, with no leakage current). 

For the low power nodes, though, it will last much longer. 

Best regards,

Edvin

[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