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?