Hi Rich,
the additional security of OpenPGP was not my primary motivation to implement things this way, when I started. It came as a beneficial side-effect 
However, I continue to claim that end-to-end-encryption is safer in the real world. I totally agree that in theory, both approaches have roughly the same level of security. After all, they use the same algorithms (e.g. RSA) and if I do not use public CAs, there’s indeed not much of a difference, because the MQ server is a machine under my control.
But exactly here, the difference in the real world starts: Since I certainly do not want to maintain yet one more physical machine, I’d run the MQ server on the same machine as openHAB (and other services, btw.). This means, this machine has quite a few doors exposed to the world and if anything is hacked, it’s likely this machine. But if using only direct transport-layer-security, a breach of this server would immediately render all communication compromised 
With end-to-end-encryption, however, a breach of an intermediate machine has no influence on the security.
But as said, this was not my primary motivation when starting the project – it’s just a side-product. To give you (and everyone else who is interested) a deeper insight, I’d like to take you step-by-step through the development process and the decisions I made:
Let’s start with the requirements:
-
The solution should be as decentral as possible, so that a network failure (e.g. damaged switch) has no influence on the functionality of a single room. The inhabitants of my house should still be able to switch on the light, even if the openHAB-server is down/inaccessible.
-
No black-boxes! All components must be trustworthy free hard- and software. Proprietary systems are a no-no. I do not want to install a spy into my house!
-
Cheap! Smart lights are very expensive. For example, a smart 24-W-LED-ceiling-light costs here (I’m living in South-East-Asia) more than 50 € (60 $US). For a simple (non-smart) 24-W-LED-ceiling-light, I paid only 18 € (21 $US). Of course, I needed additional electronic parts (opto-isolators, transistors etc.), but these cost less than 5 € (6 $US) per light.
I have 80 lights in the house. Saving at least 27 € per light saves me over 2160 € (2600 $US) in total!
Btw. the Raspberry Pis not only control my hardware, but also serve as WIFI access points at the same time. Since a raspi costs roughly the same as an ordinary WIFI AP, they thus do not cause any additional costs. Even if I counted them as additional costs, the 14 raspis all together cost only about 700 € – quite some money left from the said 2160 €. Also with standard WIFI APs we’re back at point 2. – and these black-boxes have a really bad track record, when it comes to security.
-
As simple and as robust as possible. Every additional system is an additional potential point of failure. And it causes additional work in all stages: During development, I’d need to set up more things; on my build-server (for automated tests) I’d need to install another system or invest time into integrating this into my build; I’d have more systems to keep up-to-date in production – and to repair when they fail.
Since I already used Raspberry Pis for years as network-components (e.g. firewalls) and for home entertainment (with OSMC), it was clear to me that I’d give them a try as hardware-controller. And since I made very quick progress to implement a dimmable LED-light – my prototype took me only a few hours --, I chose the Raspberry Pi.
Then I browsed the web for free smart-home-software and stumbled over openHAB. I set up the IDE and after some research and experiments, I quickly had my first dummy-binding functional. It was only a test how to register my own dimmer and control it via web-app and Android-app – no real hardware-interaction, yet. But this proof-of-concept took me only a few hours and also the openHAB sources looked pretty clean to me (not such a shitty mess like Hibernate, for example ). openHAB was chosen, thus. I didn’t even look for alternatives – the first choice looked good enough – my time was just too limited, given work, family and house building
Now, I needed a way for my openHAB binding to talk with my raspi nodes. openHAB comes with a web-server, hence it’s very straight-forward to simply use it. You’re a big fan of MQTT, obviously, hence I want to discuss the pros and cons:
Does any ready-made solution based on a message-queue-system exist for my use-case? No! I have to admit that I did not look specifically for MQTT-based solutions, but I looked in general for existing bindings similar to what I needed. And there was none. Maybe I overlooked something. Did I???
Given my findings, I certainly had to implement a communication protocol between the raspis and the openHAB-server. Even if I used ApacheMQ or any other message-queue (as you suggested), I’d have to implement the protocol myself. The queues are merely a multi-directional transport layer and do not provide anything more than that. I still have to specify what requests and responses exist, how to address the devices etc.
My choice at this point thus is: Do I send my data to openHAB’s web-server directly or do I send it to an MQTT?
What’s the benefit of an MQTT? It solves the problem of bidirectional RPC (openHAB must also be able to send a command to a raspi – not only the other way around). But that’s already all!
And can this be achieved using a mere web-service on the openHAB-server, too? Yes, very easily indeed: Using either Websockets or long-polling.
Does MQTT have any advantage over Websockets? Yes, it is easier to handle.
Does MQTT have any advantage over long-polling? Yes, it can cope better with many many many clients (thousands or even millions). But is this relevant? No! I only have dozens of clients! 
And HTTP[S]-long-polling as transport layer combined with some custom logic for the inverse RPC (i.e. HTTP-server invokes service on HTTP-client-side) is nearly as simple as accessing a message-queue.
Btw. the MQTT does not solve other problems like e.g. encryption! That’s SSL/TLS and it makes no difference, whether I use SSL/TLS with my web-server or with the MQTT-server.
The only difference it would make is that MQTT adds one more system which needs to be set up and maintained. Here we are at point 4. of my requirements. Why should I add another system that does not bring any advantage, but only more work, additional potential security holes and additional potential failures?!???
The choice for me is very clear: HTTP[S] long-polling! A very reliable and very simple solution.
After I implemented this, I had a fully functional system, ready to be installed into my house. In the worst case, simply using HTTPS or even HTTP, this would already be acceptable for the beginning (controlling only the lights at that time).
This was the situation until the middle of March. Then, I found the time to add OpenPGP-based security. This was fortunately not much work for me, either, because I had knowledge and code ready from another project – subshare. Adding OpenPGP took me only about 2 man-days (distributed over 3 or 4 calendar days wall time).
And some final clarification:
-
The question is not MQTT vs. OpenPGP. It is MQTT vs. web-service.
-
If you prefer TLS/SSL over OpenPGP (even though this is not understandable to me), you can use it. My OpenPGP-transport-layer builds on top of my simple HTTP[S]-layer (and is a cleanly separated lib). You could even combine the two, if you are more paranoid than I am.
Cheers, Marco 
