Thank you for letting me your awesome project. Now it's more clear why you need MQTT.
", I want the power plug to subscribe to the door topic in the MQTT broker (assuming this plug is a light near the door), and once the door gets unlocked, the device( or devices, one-to-one or one-to-many) should turn on. "
This clears me a lot why you want to use MQTT. Yes, your achitecture does match MQTT. On the other side, our platform is a bit different from what you approached. Your approach is more device driven independent implementation than MODE architecture. I understand it has pros and cons. Server side could be very simple, just you could use MQTT broker as it is. But you have to implement device program for each device like which topic listening to and how to handle command coming from the other different kinds of devices etc...
On the other hand, as I wrote in the previous email, we really want to keep the device logic as simple as possible. If you want to do the same thing on MODE cloud, what you have to do on the devices are 1. a sensor just sends an event 2. other devices listening to a shutdown command. That's it. Of course, you have to implement more logic on cloud server (we call is as "Smart Module") than your architecture. But, what if you want to expand your project? How to handle manage extra temperature sensor? What if you want to get weather forecast? What if you want to get extra energy cost information from PG&E and such... You would need to change more code in each device again than the architecture implemented on MODE cloud.
We can explain the same thing for ACL. MODE already provide "Home" concept and even devices don't know the ownership would be move around, but just Smart Module can handle what's going on.
About connectivity and QoS, we could provide much better solution even without MQTT. So far, even not on MQTT, you can define your QoS protocol (As you know QoS1 basically just requires round trip send and ack packets. It's not crazy difficult) Also about connectivity, you can check Device object on Smart Module or App if Websocket is alive or not (See http://dev.tinkermode.com/docs/api/models.html#device ) So you can manage the device status on Smart Module or App too even lacking of Will/Retain kind of feature.
It would be a bit tricky to convince you to migrate your platform fully implemented on MQTT to MODE cloud. Because the architecture philosophy is different from what you've already made. Originally, MQTT started as M2M protocol and expanded to IoT platform or sort of. But still we believe putting complicated logic on the cloud as much as possible is the successful key point to make IoT more versatile service.
Anyway, thank you for telling us your project. It would be great if you could try your own project on MODE, and tell us your feedback even without MQTT. You would need Websocket, but it's not crazy hard. If you are using Spark Core, you could use this https://github.com/ekbduffy/spark_websockets/ (Sorry I've never tried but definitely it could be worth to try) We also provide Mobile SDK and simulators for easy to use.