Complete NOOB to home automation here, but I’ve been an Infrastructure architect (Windows, *nix, you name it) for about 20 years now. I’ve been fascinated by the OpenHAB concept for awhile now, but paying 3 kids’ college tuitions means not a lot of free $$ to commit to home automation projects.
I’ve got multiple Raspberry PI’s and Arduinos floating around from work research projects, so I’m not hurting for hardware to run OpenHAB. What I’m wondering about is what the preferred technology is – Pro’s and Con’s of each, for instance. I’ve read a decent amount about Z-Wave and thought that might be the way to go, but then I also see devices out there that communicate via standard WiFi, and I’m thinking “why would I buy [fill in the blank technology bridge device or USB stick] if I can just have everything work over WiFi, which is already established in my house? I could dedicate an entire VLAN and WiFi network to IoT and be done…” but then I look for devices that do [fill in function here] on WiFi and discover I either can’t find it or it costs significantly more.
So, I guess what I’m wondering is, from some more seasoned OpenHAB builders, what’s your preferred technology? I’m looking for integration of dimmer switches, light switches, HVAC monitoring and remote control, Home Theatre applications (example: push one button and television, surround sound, Kodi/XMBC console turns on, surround sound goes to the Kodi HDMI input, sound is set to a preset volume level, and LED can lighting in the room dims to 60% for home theater ambiance.
I’m also interested in integrating an existing Milestone Systems (that’s security camera software) implementation into OpenHAB, so if you see motion on Camera 1 AND THEN Camera 2, do the following actions (A, B, C).
So, what communication platform has the most versatility and should I be considering? Z-Wave? Something else?
Thanks, in advance!
Well, the nice thing is that openHAB allows you to mix & match technology, so you can pick your devices based on how well they’re suited for the task you have in mind (plus maybe based on price). You can have Z-Wave and WiFi devices run next to each other, plus Ethernet comms, ZigBee, Bluetooth, … whatever. So the versatility is in openHAB, not inside the communications platform.
Then again, looking at the maintenance efforts required, you don’t want to have too many different platforms long-term.
Yes, Z-Wave is a good choice. It’s generally popular among OH users. and well-supported. And it works better when you have more nodes. But you don’t need to or should build everything using Z-Wave. For example, there’s no Z-Wave cameras (probably due to bandwidth restrictions). Simply go WiFi there.
EDIT: and just to praise @marcel_verpaalen and his work, I’m using the MAX! window sensors for all sorts of applications where I need contact sensors, simply because they’re half the price of a Z-Wave window sensor.
If your in the US insteon is also worth looking at, I have over 130 insteon devices currently. I use Z-Wave for thermostats and outside receptacles and wifi for smoke detectors (Nest). openHAB really lets you mix and match the best technologies to fit your needs.
I also agree with above recommendation.
There is not a single technology that will serve all needs, so a bit of mix would be almost unavoidable.
For your main lighting / critical stuff I would avoid WiFi, as here you want things to always work. E.g you would not want to sit in the dark cuz your WiFi router lost signal. Zwave would work even when the main controller is off.
And that is one of the main reasons OH exists. There is no one technology that has devices to support all your needs. I suspect the average OH user has at least 6 different technologies/APIs they work with to achieve everything they need. As such I have no preferred technology. I use whatever seems most appropriate in terms of effort, cost, what I’ve already got working.
- zwave for some outlets, switches, and smoke/co alarms
- nest for the thermostat
- custom build system based on a Raspberry Pi connected to sensors and relays for controlling my garage, integrates with OH through MQTT
- custom build system based on a Raspberry Pi connect to door sensors, integrates with OH through MQTT
- RFM698HW wireless network of temp/humidity, light sensors using a Raspberry Pi as a bridge between the RFM69HW network and MQTT to talk to OH
- http binding to work with REST APIs of external services (e.g. weather underground)
- astro binding to partially drive my time of day state machine
There isn’t one. But the advantage of OH is you don’t have to choose just one. Once it can talk to OH it all works together no matter what technology it is.
Zwave is very popular and you probably won’t go wrong choosing that. It is what I started with and it has probably the most variety in terms of devices.
My advice is to start small. If money is a problem, start integrating things that don’t cost anything (e.g. weather, astro, Kodi). If your Milestone Systems can generate a REST call or some other event (email) or OH can poll some page on this device to see the motion events then this would be a free integration too. I’m not familiar with whether this device has an API or how it communicates.
Hmm… Thank you all for your replies. I’ll start with Z-Wave and WiFi and see how far I get. At least now I know that spending $45 on a Aeon Z-Wave Gen 5 interface for OpenHAB isn’t a waste of $, especially if I’ll end up using it for a number of devices.
I am a beginner like you. I have setup openhab2 a few months ago and after a lot of research I decided to start with zwave. I know it depends but in my case the system is superstable. I did not have any issues whatsoever all these months working with a dozen zwave sensors
it’s true though that zwave sensors are expensive and now that I have build the basics I might consider investing some time and effort on using some cheaper sensors along with arduino / raspberry pi
You want to avoid wifi for battery operating sensors as they will not last long. zwave on the other hand will keep your sensors working for a year at least (depending on use and configuration of course)