The openHAB system has now run integrated with the alarm for a couple of days, and I must say it works really well. I’ve also changed how the connection process between the Visonic alarm an my MQTT bus is setup. Since I wrote the connector in Embarcadero Delphi, the Windows platform looked like a potential problem. However, I changed the project so the application became a console version and then it runs fine under Wine on my Linux-server. In order to have the alarm unit placed ”where it should be” I also hooked up the serial cable to a Raspberry PI instead (and use the ser2net). So – windows question solved 😉
Since I have a couple of applications, scripts and bindings in my solution I thought it would be interesting to do a short ”write up” about the design (and which parts are used). Therefore, here comes a ”case study” of my semi-production system.
Overview of the system
This image gives a short overview of how the components, applications and hardware are connected to eachother. I’ve tried to use consistent color for same things as described in the image.
RabbitMQ with MQTT plugin
This is a central service in the system. RabbitMQ is a message broker for the AMQP-protocol in its default setup. However, since most of the things I use actually communicates via MQTT, I added this protocol as a plugin. RabbitMQ also supports a lot of different (other) protocols if the needs grow larger here. I think the use of a message broker like this will be player ”to count on” in the future where the area of ”Internet of Things” is taking more and more space in discussions and deployments.
More information about RabbitMQ can of course be found on their web site http://www.rabbitmq.com/
openHAB – empowering the smart home
This is the next central service in my solution. openHAB is a Home Automation system which works a bit like the message bus described under ”RabbitMQ”. The application is Java based and uses the Java OSGi framework for extending its functionality by using a lot of different plugins (or bindings as it’s called). A list of the bindings I use will be described below.
What made me choose openHAB was the great amount of plugins as well as it’s capability of offering a vendor agnostic bus on which different modules (action handlers, bindings, io handlers etc) can communicate to each other but not be depending on each other. Of course, I’m also a person who likes the opportunity of writing my own scripts and actually do the ”last row” that makes things happen. Since it’s free, it were no cost of deployment – certainly a good thing!
So, bindings. Bindings are used in openHAB to make the system ”compliant” and integrated with ”any vendor or device” as long as it is controllable in some way. For a complete list of bindings, please have a look at the web page of openHAB (and actually, the wiki page). Since the system is open source and pretty well documented, there is also possible to write own bindings in order to extend the functionality further. Been there, done that…
The bindings I use in the deployment is as follows.
Sonos binding is used to control our main Sonos zone. By control, I mean to send commands like Play, Pause, Stop and next track. I’ve also added rules and actions to load different radio stations. My intention is to also use the Sonos system as voice announcement device whenever a play command is commited to the MQTT-bus. This function is today handled by a RPi and a python script.
The Pioneer binding is only used for testing today. Of course it should be integrated so whenever we are planning to watch TV or a movie, the correct settings are set to the Pioneer receiver. As far as I’ve tested now, the binding works perfectly.
This is also a test implementation but works fairly well. Samsung TV’s that can be controlled by their smart phone app are supported. Unfortunatly our main living room TV is too old for this, so I’m stucked with trying to use a IR sender that could be controlled from openHAB (iTach or something).
Z-Wave (Aeon Labs Series 2 USB dongle)
This binding is (guess what…) used to control my Z-wave network of devices. Today, only a couple of Fibaro switch units are used in the Z-wave network. Works very well and feels a lot more robust than for example my Nexa units.
The hole idea of implementing some HA solution was actually born from this point of view (Z-Wave). My first application was to synchronize the state of two ”zones” of window LED’s. They were supposed to be one zone when they got installed, but because of a misunderstanding, they became separated. This was a one line rule in openHAB to solve – fantastic 🙂
Nexa – via exec binding
This chapter should probably cover the Exec binding which makes it possible to execute shell commands from rules in openHAB. I use this primarily as a way to send commands to my Tellstick DUO unit. The Tellstick then sends ON/OFF commands to my Nexa units. Even though Z-wave units are more reliable and quicker, the Nexa wins the price-game. So for small lamps placed around the house, I use Nexa wall plugs. Have worked very well.
I use the NH binding to discover the presence state of some phones, but primarily the living room TV. If the TV responds to PING then openHAB thinks that we are still alive, and won’t shut down the light on the evening. This together with the motion detectors has addressed the problem of setting ”light off” to a ”hard coded value”. Now I check the presence of our living room from 11 PM. If there has been no presence for a couple of minutes, the lamps goes off. So far it has worked flawless.
I wished I could say that I have had many things to thank this binding for, but I really haven’t. This is because I only run OwnTracks on my own cell phone, and can therefore not be able to track my other family members ”home presence” with this binding.
The future plans would of course be to integrated a chain of decisions like ”oh – it’s MY phone that has became active withing X minutes, and now someone disarms the alarm – then openHAB will greet the owner of MY phone welcome”. Also (much more important) – if the house is empty (no home presence) then set the alarm to ARM.
So – more experimental exercises will be done here.
FreeSWITCH is a software PBX like Asterisk. The FreeSWITCH binding is used to inform the system on incoming calls, active calls and ”message waiting” (=MWI). The binding is not actually included in the openHAB distribution (addon package) today, but is available as download anyway. Many thanks to Dan in the openHAB community for this contribution.
Additional applications or scripts
This is an application that I wrote in order to communicate with my alarm. As mentioned in previous post, the protocol specification is reversed engineered and I send all my gratitude to the guys at Domoticas forum. With this application I’m able to detect zone events and actually log pretty much everything that the alarm notifies me about (state of the zones, units, events of any kind, trouble, fire, etc). The physical connection to the alarm is done via a Raspberry Pi unit hooked up to the serial port and then the ”ser2net” service is used to publish the serial connection over TCP/IP-port. A fantastic solution that makes it easy to access the serial port of the alarm even though my server is in another place.
Everything that comes into this application and that is parsed correctly is then send to the MQTT bus on a specific topic. This makes it possible for openHAB to react on and for example show alarm state information. As actions I’ve implemented support for notifying both cell phones and voice announcement services on changes like Disarm, Arm, Arm home as well as when someone opens/closes the doors. This information should in a future also be sent to the TV’s.
Since I’ve only tested the application with data coming from the PowerMax Complete unit, I have setup a http post command to be used in order to Arm, Disarm and activate Home mode. The http post is sent to the PowerLink2 unit in the alarm.
A script found in the Plex community (GitHub) which monitored the log files of the Plex Media Server and then sent out notifications on different (configured) ”channels”. In this script, I added MQTT as a channel and can therefore have openHAB reacting on Plex changes. In the future, I will replace this implementation with a web socket version which does not poll the log file but rather ”reacts in real time” on events. Also, it would be nice to use the possibility of Plex to get a list of active clients and then use the Web API to be able to control them individually. A fun fact is that it’s almost equally possible to control mobile plex clients as well as Plex Home Theatre clients. Just because you can 🙂
This python script is triggered by a cron job and does a web api query towards the weather service forecast.io. The script is found here
When the script has run successfully the downloaded weather data is published under a MQTT topic. This is in my setup only used to detect when sun rises and sets. Actually – I also added the ”forecast summary” text so I can see a one liner of todays and tomorrows weather.
Other units integrated in the solution
PiFace Control and Display
As described in previous post I have deployed a PiFace CAD unit as a ”scene selector”. This is a actually a simple Python script running on the unit and sends commands to openHAB via MQTT.
The plan for this unit is to implement a ”menu system” so that more things can be controlled. Things in plan is
- Volume control of Sonos system
- Next track of Sonos system
- Scene control for ”Watch TV/Movie”, ”Dinner”, etc
- Scene control for light (as today)
Let’s see how it goes 🙂
This is also a Raspberry Pi with a MQTT integrated Python script. What it actually does is to listen on the topic ”home/notifications/SendToSay” and then takes the received string, makes a wget call to translate.google.com and saves the data to a mp3 file which is played by mplayer. Hooked up to some small computer speakers make this a really cheap sound announcer. The script will be extended so that also the topic ”home/notifications/SendToPlay” will be subscribed to. This should make the script play a sound file stored on a network or local URI. Think of it as the classic ”let active the dog barks if the motion detectors detect motion and the alarm is in ARM mode”.
This was a very ”high level” description of an early implementation. It has a lot of ”improvements” that could be done, but I think the next step is to actually extend the number of Z-wave units. I’ve also some plan to measure temperatures and power consumption with home built Arduino units. Guess what they will be hooked up to…? Yep, MQTT feels like a good idea even here 🙂
Hope someone had the time to read it all the way through. Feel free to leave a comment or ask questions.
Live long and prosper!