So I just learned about OpenHAB recently and would like to get rolling on it. My main question is the setup of OpenHAB hardware wise. I read lots of people’s threads and everyone seems to be one off, which I think is cool, and how I plan to go. What I’m curious about is the main hub running OpenHAB vs the sensors themselves. In my setup I’d like my home server to run OpenHAB, and I’d like to custom build the nodes as cheaply as possible, perhaps something like this. What I don’t understand is the middle man. I keep reading about the Z stick or people building a arduino “gateway” of sorts. Say I built a simple sensor using an arduino. Do I need a gateway to get it to talk to the PC running OpenHAB?
You are asking about the signal transport level between sensors and OH server.
For your custom build, you could use (a) a wired link from the Arduino to GPIO pins on a Raspberry Pi 2, or (b) an Ethernet link if you equipped your Arduino appropriately or © a wireless link. That wireless link might be (1) Bluetooth or BLE, (2) Wi-Fi . (I don’t know of any way to equip an Arduino with z-wave interface, but someone else might…)
The cheapest way would be a wired interface to GPIO, but the feasibility of that depends on the physical location of the sensor and your server (GPIO is supported on the *nix OS versions where OpenHab runs - Debian, Raspbian, OS/X etc would fit in that class although I’m not sure how your wireup the physical interface on other than a Pi where the physical pins are accessible.)
If you can go Ethernet / Wi-Fi, you can post traffic / get info to OpenHab using MQTT protocol. See this link for an example. Arduini/MQTT sensor example
So if you are wanting to use Z-wave sensors and actuators that is what the z-stick is for. It acts as the controller for the z-wave network and openHAB knows how to talk to it to send/receive.
For the DIY route a lot of solutions follow the same general architecture:
- Remote Arduinos with a cheap and low power wireless transceiver
- A not as remote Arduino that bridges the low power wireless to your LAN. This is the gateway.
- An MQTT Broker (Mosquitto seems popular) which standardizes the message traffic to and from the Arduino gateway.
- OpeenHAB installed on somewhere else which sends commands and receives readings via the MQTT broker.
There are lots of variation and I’d bet that most people have a hybrid environment with some z-wave, some hard wired via the GPIO, and some wireless. Some communicate via MQTT and others communicate directly with openHAB. One of the areas where openHAB really shines is it provides a layer of abstraction over all the little details of how the different technologies work so in your rules and configs you don’t have to care.
Very cool, thank you both for those answers. I do a lot of this kind of stuff at work and have used a lot of various communications software and hardware devices (I’m a software developer by day). It sounds like I could start one way and end up mixing and matching things.
I suspect most of my sensor runs (some door/window sensors, some temp/humidity) would be less than 50 feet, so it sounds like a arduino or pi with a bunch of I/O would be the way to go. Is it ok to run lengths that long straight to the I/O?
I do like the Z-wave stuff too but don’t want to commit to it first.
Does the MQTT protocol allow both sending and receiving? I’m unfamiliar with MQTT but have used several others like ZMQ or ROS messages. I’ve also built custom ones with Google Protobuf.
I am using the very cheap esp8266-1 with mqtt software as simple nodes in my OH system. I also have some ethernet (wired) arduinos running mqtt. But I also have rfxcom, zwave and http devices in the system. I think the possibility to use so many different protocols and hardware solutions is the main reason to use OpenHab.
1 Like
Absolutely you can both send and receive. Mosquitto seems to be the broker of choice and Paho seems to be the library of choice. I can say that setting up Mosquitto on my system took less than an hour and sending and receiving messages too about 24 lines of Python code from some custom scripts I wrote.
From the little I know about ZMQ I’d say it is very similar. I too do professional development and I come from a mainly JMS and AQMP messaging protocol background and can say MQTT is way lighter weight and requires way less configuration even when enabling encryption and authentication.
One really nice feature from a system monitoring perspective is the Last Will and Testament. If an MQTT registers a LWT message and topic, when the server detects the client is no longer connected it will post that message to the topic. You can then have openHAB listen on that topic and generate alerts or take restorative action when the connection is lost.
Because it is so light weight and requires so little configuration I think it is one of the preferred messaging bus technologies for home automation in general, not just openHAB.
Would you terribly mind giving me a link or some further description on setup of these simple nodes?
Very cool! I’m really stoked to pick a design and get started. I think I might try a couple of node types and then run with the one that works best. It seems like it’d be good to have some zwave in there, as some of the thermostats I’ve looked at are zwave.
Here is good starting point: https://github.com/Imroy/pubsubclient
There are tons of information about ESP8266 + arduino ide + mqtt on the net.
Just to add another viewpoint: MQTT seems to be a very popular choice for implementing new sensors. I have worked with MQTT-based sensors before, but when I started building temperature/humidity sensors, I decided against using MQTT.
My rationale is simple: I need another component (the broker). The broker can go wrong at any time, and for mosquitto (which seems to be the most popular choice) I saw some outages at work. On the other hand, with the readily available webserver components for the ESP8266, it is very easy to create a sensor that can be queried just via HTTP and discovered using MDNS.
HTTP is a component included in OpenHAB, it is well-understood and easy to use. So for me, it seemed like the better choice. But don’t get me wrong: I’m perfectly fine with other projects going different routes. In fact I think it is interesting to see how different ideas compete and evolve. The nice thing about OpenHAB is that it simplifies the integration of very different protocols, so even if you decide to abandon one technology and go for another one, you can keep your rules and datasets.
Maybe you want to look at New binding for home made hardware which is what I did to solve a pretty similar problem. The only drawback of this solution is that the XBee modules are about ~25 € each, but I got a very stable network which is self organized and independent of the entertainment (wifi) network.
Wow thanks again everyone for all the resources. I’ll have to well document what I go with and try and contribute back to the community.
@gonium I like that approach too, I wonder if there’s any difference in battery life between the two?
I really want to do everything in my power to avoid batteries altogether. I already have a PoE switch and was thinking a PoE solution might be awesome, but then it seems PoE parts are fairly expensive unless I design my own.
@juergen_richtsfeld Yeah I like the XBee too, I’ve used it in a project before and liked it. But yeah due to cost I think I’d easily go with the ESP8266 over it.
You mean HTTP vs. MQTT? I don’t think that there is any difference between the two in terms of power consumption. Both need a running wifi connection along with an IP stack - so basically, the processor is running most of the time.
I have my sensors connected to mains power all the time - I did a quick check and found that they are using 2W of power each. The main source of power loss seems to be the power supply itself. I had a bunch of old 3V3 wall-wart power supplies sitting on my desk and put them to use, no special consideration here.
But @mjptec mentioned in this thread that he wanted to investigate operating the sensors from a battery. The main power draw occurs when wifi is switched on, but in deepsleep mode, the ESP8266 draws only around 20 microamps. I therefore think it is a viable option to have the ESP8266 powered down most of the time and then wake up just to take a measurement and submit it to OpenHAB.
No matter what your technology, if you can push the data from your energy constrained sensors only when necessary as opposed to setting up the server to poll for the data it will be more energy efficient. I think this is one of the drivers behind having a gateway device to bridge between the ESP network and the IP network, one that has wall power so energy isn’t a problem. And once you have a bridge, it makes sense to configure that bridge to provide a nice and easy interface to the data, be that an HTTP REST API, MQTT, etc.
@rikoshak: I agree regarding the push vs. poll strategy. An energy-efficient sensor should sleep, then push its measurements somewhere, and then sleep again.
BUT: (here comes my not-so-secret plan): I don’t think you need any special bridge. I intend to try to use the OpenHAB REST API directly, making the raspberry pi running my OpenHAB instance effectively the bridge. It should be as simple as using Arduinos HTTPClient class, but I haven’t tried it yet. Another advantage of the stick-to-http-strategy 
As the saying goes, “there is more than one way to skin a cat.” 
I am interested in your approach. I’ve settled on MQTT primarily because I already had it set up (I played around with OwnTracks for awhile) so I already had the broker set up and configured. It also seems really popular so I never changed. I also like the Last Will and Testament feature which really helps me detect when a client goes down (my Raspberry Pis are very flakey, though I’ve never have my Mosquitto server go down).
So my questions concerning your approach:
-
How will you manage actuators (e.g. a relay)? I can’t see a way to use this approach without having the remote device either always on the network or constantly polling. Perhaps this approach mainly works for sensors only. (NOTE: I’m not implying that the MQTT approach has an answer for this either).
-
What are you running your openHAB instance on and how are you getting it to talk to the ESP8266 network? To my knowledge there isn’t a binding for it yet; are you writing one or planing on using the Exec binding and scripts? Essentially this is the purpose of the bridge, to bridge the ESP8266 network and your LAN. Would you approach work on a general computer/synology or would it require openHAB be running on something that has GPIO pins?
I have five Arduinos with a bunch of sensors and RMF69HW transceivers all in parts in a drawer somewhere that I plan on building and deploying. I’m pretty much stuck with a gateway no matter what because I have openHAB running on an old laptop but I’m sure I can learn something from your approach.
Before I ever discovered OpenHAB, I was looking at this solution. Although it requires some SMD soldering, it’d end up around $6 per node and be hard wired ethernet. I think my pie in the sky solution would be to modify this solution to be powered via PoE (I already have a PoE switch) but that may be too much of a task to start with. I already have an arduino with ethernet shield laying around so I’ll probably begin with that as a test. Since I have the shield I suppose there’s no need for any gateway or anything, I can just send the data via IP to OpenHAB correct?
Yes, with the right code you can plop a web server on it or a HTTP client like @gonium 's approach, plop MQTT client on it like I’ve been talking about, or come up with some other IP based approach. There is a TCP binding if oyu prefer working at a lower level.
1 Like
You may also want to look at mysensors.org
They now support ESP8266
I also have been using mysensors for about a year, and the system works excellent, I use 12 or 13 of them around the house, some battery sensors others hard wired to a common power supply. They range from dimmer to temperature sensor. The range is over 40m in my case as they act as a repeater node if they need automagically. I will be honest in that the learning curve was 4 to 6 mths, and confidence time about 4 mths. My only gripe right now is not keeping track of software versions I use and what each node actually does! mysensors runs on a cut down MQTT from what I can see and I use a Arduino Ethernet gateway with 2nRF01 long range device. The MQTT service has never faulterd in the months it has been running, neither has my pi which is the Openhab server.
I like the Openhab platform as it also can talk to kodi, and I can send json requests, http requests, apply xml transforms to web pages trigger cctv alarms, its totally amazing what it can do. Needs a new interface though ;-(