I’d like to just second the MQTT approach. Installing a broker onto the Raspberry Pi is incredibly simple, and it’s easy to debug since you can subscribe to the messages on another PC to check your underlying MQTT network is fine, before proceeding to put those into OpenHAB.
I’m also trialling the NLRF+ wireless things for Arduino at the moment, and they’re an absolute ass to work with. They don’t like a clone Arduino’s 3v3 (original boards seem fine), they dont like long jumper cables, and theyre just difficult to work with. Eugh.
Part 2 of my guide for OpenHAB on Pi was published yesterday, which gives you a complete introduction to MQTT protocol and how to get it working on Pi/OpenHAB. I used Ethernet shield for Arduino but the wireless ones / ESP2866 will work fine too. http://www.makeuseof.com/tag/openhab-beginners-guide-part-2-zwave-mqtt-rules-charting/
As for your questions, @rlkoshak :
I currently only have sensors - my actors are Homematic components. But if I had to implement an actor it would be always on - since most actuators switch power or depend on power to fulfill their function they would not depend on batteries. Another reason for the always-on approach is that the state of the actor might change locally (i.e. a local button to change the state of the builtin relay). So the actor should always represent the state of whatever is connected to it.
Maybe there is a misunderstanding: the ESP8266s are just wifi devices. They sit in my internal network just as my RPi running OpenHAB is. There is no physical bridge necessary. If you look at the readme of my project you will find how I integrated them with OpenHAB: I simply use the HTTP binding and a JSON transform. No need to write a binding for that.
BUT: my devices are currently always-on. I haven’t thought this through, but if a device would sleep for some time, the only viable communication direction would be from the device to the OpenHAB instance. That should work for a sensor, but for an actor this seems inadequate. If I press my light button I want light now Another reason why actors should be always-on.
Another piece of excellent, well-written work.
Ah. Clearly my knowledge of all of these wireless chips is not that good. Most of what I’ve been looking at has been using lower power and simpler wireless protocols than WiFi so a gateway is required.
Z-Wave is certainly not a cheap choice, but effectively one is confronted with the problem of needing to use protocols which the products you intended to use communicate with. This is a good reason for multiple automation networks, as different communication needs can be handled appropriately to the budget, requirements, etc.
For example… One-Wire is a cheap and easy way to run a bunch of wired sensors around a resonably small area. It is a daisy-chained network with basic (cheap) cable, so you don’t get into the high cost of running many pairs of more expensive copper wire back to a central location. The devices are also cheap, and have been around for quite a long time. (there is a ready-to-use 1-Wire/Ethernet gateway which works with OpenHAB)
There is also 433MHz which can do A LOT on a budget, but if you want to avoid batteries then wiring would be best. Honestly, I tend to agree about avoiding batteries, but sadly there aren’t many products out there that you can easily externally power (and they’re mostly wireless).
You mentioned the hub, sensors, and gateway… for me, from an architectural perspective, it is important to also keep in mind the connectivity (network, protocols, transport) and network interface. The choice of sensors/actuators, network, interface, gateway, etc will all be dependent on your needs and how you architect your solution. MQTT is TCP/IP level, so once you have a network interface from whatever network to OpenHAB, you can put everything on MQTT (I do this with OpenHAB + RFXCom binding + MQTT binding). Or you can use MQTT directly from something like an Arduino.
Regarding your desire to use PoE… I too have a PoE switch… and would love EVERYTHING to run on PoE (for many reasons). However there are some reasons why this is not feasible for cheap sensors as the electronics required for appropriate power conditioning are apparently not cheap. There is a guy called Jonathan Oxer from Superhouse TV and Freetronics who has designed a custom Arduino which has PoE (and Ethernet obviously) built in for much less than adding a PoE shield to an Arduino. He has also wired his house almost entirely with Ethernet, PoE, and Arduinos to control everything.
Interesting reading all of this. There is a ton of info on Arduino + ESP8266 + MQTT on the net indeed. In fact, there is so much that I lost track. Can anyone point me anywhere to a simple example of how to use the ESP8266 as WIFI solution for arduino? In other words: I want to use the Arduino because it can handle a ton of sensors/relays etc. at once, and I need a simple bi-directional WIFI connection to my RasPi Openhab solution. I have succesfully used the ESP8266 as single temp/humidity node through MQTT, and the same with an Arduino with Ethernetshield. Now I want the Arduino wireless and the ESP8266 seems a valid choice.
Thank you, Yancy! However: I don’t have a Nodemcu card, I have a Arduino Uno, a Mega and a Nano and a couple of ESP8266-01’s… Before buying more gadgets (alsways cool) I figure I should be able to use what I already have…
Or am I missing the point completely?
I’m pretty new to all this Arduino stuff so learning as well. You may have to glean some of the code from this site, or even check the forums and see if someone else has already done this with a regular Uno or Nano.
Peter I hear you too. I have a pile of electronics: Arduinos, ESP8266s, etc, just need to devote some time to putting a few samples together and then decide what my “production” units will be. I want to build a few arduino “nodes” to hook up several door/window magnetic switches and temperature/humidity sensors to. I also want to wire them all since my attic is easy to get around in, and try to use PoE where I can to simplify things and not have to run lots more circuits.