Raspberry-Pi-controlled hardware with separate (remote) openHAB-server

Hi everyone,

I finally found the time to write a few lines into the wiki and thus thought, I’d share my smart-home-project with you:

Just in case, this might be interesting to you – at least the real nerds of you :wink:

I developed most of it already in January, but my new house was not yet ready to move in. We moved quite a few months later. Hence, I run this software productively in my own house for a about 4 months, so far, with an openHAB 2.1 server (installed on my home server) and 14 Raspberry Pis distributed over 4 floors.

To get things clear: This is not about installing openHAB on a Raspberry Pi! This is about having many Raspberry Pis controlling custom hardware (soldered it myself – circuit plans in the GitHub repo) and the openHAB-server running somewhere else.

The communication between nodes (Raspberry Pis can talk with the central openHAB server and with each other) is secured by OpenPGP. Probably, this is the most secure smart-home-solution available, because at least the Raspberry Pis don’t open up anything (they act as clients to the HTTP server openHAB starts, anyway) and all communication is encrypted and signed using OpenPGP.

Well, if you are interested in this project and have questions, please ask! I’m usually very busy (working) and might thus not reply quickly, but I’ll try to respond.

…and I’ll try to add more documentation on the GitHub wiki. Right now, it’s still incomplete, but I thought, I should tell you now, before someone else might start a similar project.

Cheers, Marco :slight_smile:


You’re welcome!

SSL/TLS secures only the direct transport – i.e. the direct connection Raspberry Pi <=> openHAB-server. But in my house, one Raspberry Pi can talk with another Raspberry Pi and I wanted true end-to-end-encryption.

I need raspi-to-raspi-talks for example with my veranda: Its lights are connected to the raspi in the garage, but the switch in my livingroom is connected to my livingroom-raspi. Hence the livingroom-raspi sends a message encrypted for the garage-raspi. At the moment, all communication works via the central openHAB server, but 1st it does not need to understand these messages it relays (it’s sufficient that it only relays messages from nodes it trusts) and 2nd the communication protocol might be easily changed/extended to use any transport underneath. So if you would like, you could e.g. use JMS (e.g. an ActiveMQ – i.e. MQTT as you desire) and don’t need to change anything on the communication’s security (provided by OpenPGP).

Also it’s IMHO not really true that MQTT is easier to set up: You already have the openHAB-server running (obviously), while a message queue server needs to be set up additionally. And you then do not only have one more system to set up, but also to maintain.

And if you really want everything to be secure, you have to create+sign your SSL/TLS certificates – that’s exactly the same work as gpg --gen-key ....

One more very important point is that I wanted to avoid all 3rd party dependencies. My devices should work with openHAB alone – no other process needed.

GnuPG can be used to maintain the PGP key ring on the system (e.g. to create or sign a key), but it is not needed for my devices to function. Once the key ring is there (plain files), everything works as long as the openHAB-server and the intellihouse-raspi-process work. Btw. I use BouncyCastle and of course did not re-implement OpenPGP myself :wink:

SSH tunneling is IMHO more an administrative tool than sth. I’d build inside a Java plug-in for RPC.

Actually, the starting point is openHAB opens an HTTP server – it is always there. I can easily use it by registering my own servlet. Everything else would need additional systems. And openHAB does not even support HTTPS and authentication out of the box – I use Apache2 for this purpose. This is fine, of course, but I certainly did not want my device-to-openHAB-communication to depend on Apache2. I wanted it to work with the minimum – the existing openHAB-HTTP-server and an HTTP-client (JRE).

This and the end-to-end-encryption (mentioned before) are my most important reasons.

And one more thing: When you use the Oracle JRE (and on the Raspberry Pi, there is AFAIK no OpenJDK available) and the JSSE (which is done by default when you use any common HTTPS component instead of re-implementing things), then you can use only 128 bit encryption :frowning:

In order to use 256 bit encryption, you first have to install the “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files”. This would not be a problem, if you had to do this only once. But whenever the OS update (=> apt update && apt dist-upgrade) brings a newer java, the JCE is gone :frowning:

With me using BouncyCastle directly (no JSSE) for OpenPGP and symmetric encryption (for speeding up things – read this comment for details), I can always use 256 bit symmetric encryption and 4096 bit RSA (both the most secure currently available).

Yes, I am paranoid. And no, for lights, it does not matter, but for a lock to my house, it does :wink:

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 :wink:

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 :frowning: 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:

  1. 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.

  2. 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!

  3. 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.

  4. 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 :wink: ). 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 :wink:

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! :smiley:

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:

  1. The question is not MQTT vs. OpenPGP. It is MQTT vs. web-service.

  2. 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 :slight_smile:

I feel the need to specificly reply to this: Just because OH can integrate multiple technologies neither implies that this is desirable nor that it provides any advantage whatsoever. Just because you can add a trailer to your car does not mean you always do (and drive shopping groceries with the trailer) :wink:

Just as you don’t add a trailer to your car, when you do not need it, you also don’t aim for an heterogeneous infrastructure with as many sub-systems as possible. Or do you??? I don’t!

I try to avoid every complexity and every sub-system I can. I only add what is really needed. And I do not find this requirement ridiculous, at all!

I seriously wonder how you can find this ridiculous – are you administrating any system yourself? Are you not pissed, if any of them fails for whatever reason? Do you really aim for the additional work of keeping yet one more system up-to-date (especially, if it is not integrated in your OS’ apt update && apt dist-upgrade)???

Additionally, I did not choose OH for its capability of integrating different technologies. I chose OH, because

  1. it saved me the work of implementing an own web-app;

  2. it saved me the work of implementing an own Android-app;

  3. it saved me the work of implementing an own “master” control server (which btw. I would not have done in this centralized way, if I had implemented it myself – I would have opted for a distributed system with every node being able to take control – resiliance is key – but this is an entirely different topic).

Of course, it is great that OH can integrate other systems and I might make use of it in the future – if I find smart hardware that comes with circuit plans and software sources (which I doubt will be any time soon).

Don’t you think that asserting my incompetence is a bit too bold and arrogant without even taking a look at the sources? I have quite some experience in applied cryptography and I would be really interested in you pointing out a weakness in my solution!

Unless you do this and come back with a real argument, please don’t bother me any longer. I have the impression, you are just a certified talker! I’m a maker: I produced something functional and I donated my solution to the world as free software. So either you too contribute sth. (not necessarily code, but at least qualified arguments – implying I was incompetent is definitely insufficient) or shut up!

Concerning the lines to be drawn between what dependencies to add and what to better implement yourself, it is a pointless discussion, because multiple people weigh the pros and cons differently. And no, I did not implement my solution because of “Not Invented Here” – as already pointed out before in detail, I use BouncyCastle and many other libs for multiple reasons. But as said: Someone implying I’m incompetent and “don’t know what I’m talking about” does not deserve any further time from me. Discussion ends here – at least until you point out a real weakness in my solution or otherwise contribute sth. really meaningful.


Please, before arguing in such a harsh tone against one of the highly honored members, step back for a moment and cool down. Some statistics?


  • 8 days visited
  • 3h read time
  • 84 posts read
  • 0 given
  • 3 topics created
  • 16 posts created
  • 13 received


  • 740 days visited
  • 34d read time
  • 62.8k posts read
  • 783 given
  • 88 topics created
  • 8.4k posts created
  • 1.9k received
  • 164 solutions

Please pay attention especially about 164 solutions, and these are only the ones which were marked as the solution!

There is no need to be harsh, Rich stated that computers are his profession, and while even professionals can wander, there is a good chance that his objections are valid :wink: this is no assault against you or your work!


I think I was being misunderstood in my posts on this thread and coming across like I was attacking @nlmarco and his contribution to the community.

I apologized for any hurt feelings. I did not intend for this.

I’ve deleted the offending posts and withdraw from any discussion on this.

Thanks again for your contributions to the community. It is not important I understand it or agree with the approach or claims.

Hi Rich,

your apology is accepted, of course.

Likewise, if this was really just a misunderstanding and my reaction thus too extreme, I apologize, too.

Dear Udo,

I do not care who talks to me, but what is said.

I understood that someone publicly stated my approach was “ridiculous” and implied “I don’t know what I’m talking about”. Hence, my end-of-discussion-red-line was clearly crossed.

It is totally fine to professionally criticize my solutions! I’m even very happy about such criticism! And most happy I am over a good pull request!

But it is not OK to unfoundedly (without reference to any code!) imply I had no idea of what I was doing. This is not constructive criticism, but an ad-hominem-attack.

I already wrote to Rich (above) that his apology is – of course – accepted and if I just misunderstood, I apologize, too. So, I hope that this topic is done, now.

So is mine. For much more than 20 years, already :wink:

1 Like