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]

Hello,

If the lock is connected to an openthread network that has a border router, the devices will be assigned an IPV6 address that is reachable from outside the network (although you need to keep track of their IP addresses). 

I am not sure whether you are familiar with Bluetooth Low Energy (BLE), but SSEDs are quite similar to BLE devices, who only uses the radio in short bursts in a given interval which the SSED and the parent router has agreed upon.

Please note that for SSEDs to work (as well as for SEDs), you need to have a parent router which needs to be a full thread node. These nodes will draw more power than the SSEDs, because they need to have their radio left on 100% of the time. Typically, mains powered thread devices will act as the full thread devices (FTD), while the sleepy end devices will be battery powered. Sleepy end devices does not increase the radio extension of the network.

If you want your nodes to have the new credentials 5-10 seconds after they were created, I suggest you set the communication interval/period to 5 seconds. Then the parent node will keep the messages for it's child(ren) until it has been transmitted during one of it's wake up slots.

Best regards,

Edvin

[metalgear12]

Thanks for that info Edvin but I am still a little confused about the following:

1. Regarding your comment above "parent node will keep the messages for it's child(ren) until it has been transmitted during one of it's wake up slots" How will the parent node "keep the messages for its children". 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?

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. 

Also is the nRF52 better for this or the nRF53?

[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