Simple on/off rules with OpenHAB

So as a quick follow-up to yesterday’s post I wanted to give you a simple rule-set to get started with.

In that post we got OpenHAB up and running. We were also able to turn the Christmas tree off and on via the web ui. In this post we need to automate that.

Log into the OpenHAB box and cd into the OpenHAB directory (in our case under /opt/openhab)

cd /opt/openhab/configurations/rules
vim default.rules

We will sock in there the following code

rule "TurnOnTree"
when
  Time cron "0 0 18 * * ?"
then
  sendCommand(Z_socket1, ON)
end

rule "TurnOffTree"
when
  Time cron "0 0 22 * * ?"
then
  sendCommand(Z_socket1, OFF)
end

That’s really it. OpenHAB can re-source the config files while running, so at 6pm your xmas tree will light up, and at 10pm it will turn off.

Because the project uses the Quartz Scheduler, it is helpful to read their documentation

The Simplest OpenHAB Z-Wave set up

I have recently become interested in home automation. Mostly because I like to play with technology, not becuase of any real pressing need for it.

I decided to pick up some Z-Wave equipment at the recommendation of my friend Bob.

I purchased the following:

The Aeon Labs ZStick

And a GE 45603 Socket

The first step is to associate the dongle with the socket. This is done easily. Just plug the outlet into the wall and walk up to it with the dongle in your hand. Press the button on the dongle, and then after the light begins to blink, press the button on the socket. The dongle will blip and then resume the slow pulsing. That’s it, you now have a mesh z-wave network of two nodes.

Then take your dongle and plug it into the machine you plan to use as your OpenHAB server. This can be anything that will run Java most likely. I used an old tower I had on hand and slapped CentOS 7 on it.

Install Oracle’s Java via RPM (jdk-8u25-linux-x64.rpm):

# yum install jdk-8u25-linux-x64.rpm

Then pull down the latest OpenHAB. You’ll need the Runtime Core and the Addons archives.

Sock OpenHAB on the server under /opt:

# mkdir /opt/openhab
# cd /opt/openhab
# wget https://github.com/openhab/openhab/releases/download/v1.6.1/distribution-1.6.1-runtime.zip
# unzip distribution-1.6.1-runtime.zip
# cd ..
# mkdir addons-openhab
# cd addons-openhab
# wget https://github.com/openhab/openhab/releases/download/v1.6.1/distribution-1.6.1-addons.zip
# unzip distribution-1.6.1-addons.zip
# cp org.openhab.binding.zwave-1.6.1.jar ../openhab/addons/

Now we have the code deployed, and our z-wave bindings in place. Let’s finish up the configuration and fire this up.

First openhab.cfg

# cd /opt/openhab/configurations
# cp openhab_default.cfg openhab.cfg
# vim openhab.cfg

Find out where Linux put that guy.

# dmesg | grep cp210x\ converter\ now\ attached
[    6.237436] usb 6-2: cp210x converter now attached to ttyUSB0

Alright, now that we have that change the following line:


zwave:port=/dev/ttyUSB0

Now, let’s create our items file


# vim /opt/openhab/configurations/items/default.items

And add this.


Switch Z_socket1 "Christmas Tree" (Lights) {zwave="2:command=SWITCH_BINARY"}

Now, let’s edit the sitemap so we can manipulate that item using the web interface


# vim /opt/openhab/configurations/sitemaps/default.sitemap

And add this.

sitemap default label="Main Menu"
{
        Frame label="Christmas Lights" {
              Switch item=Z_socket1 label="Christmas Tree" icon="switch"
        }
}

Now fire up the server and navigate to the web interface.

# cd /opt/openhab/
# bash start.sh

You should now be able to navigate to http://yourhost:8080 and there should be an on/off switch for you to play with.

Certainly not plug and play. But if you’re technically savvy, this should get you up and running.

Next up you can start to write rules for controlling your home.

mcollective-yum-agent release 0.4

I decided that I will actually do releases of the MCollective yum agent, though there will likely not be many.

Because I use Github as my only remote I sometimes push broken code so I can pull it to another machine later to keep working. This could result in an end user pulling the broken code and well, being generally annoyed.

With the latest additions to add `list` as a subcommand, I figured I’d tag a release and then people can nab that instead.

The .4 I picked out of the air. I feel like I am about 2/5ths done, so .4 seemed appropriate on the way to a 1.0 release.

I am also planning to produce a RPM that I will publish in a Yum Repository. Seems like blasphemy that a yum agent doesn’t have it’s own repo/rpm.

Releases URL:https://github.com/slaney/mcollective-yum-agent/releases


Change Log for 0.4
* Added `list` subcommand
** See docs for usage

yum mcollective agent

Almost 3 years ago I created 2 MCollective Agents for use at my last employer. One was a `yum` specific agent that allowed us to automate the patching of their brand new 500+ Redhat Enterprise Linux footprint. The second agent, shellout, allows you to execute arbitrary shell commands on hosts concurrently. Both agents enjoy the rich filtering capability you get for free with MCollective.

The Yum agent was by far the more popular agent. I think the Shellout agent scares people and it should, but nonetheless it has suffered poor adoption.

My concern recently has been that if you wanted to manage the Yum agent in your environment you either had to “cut” your own release and make an rpm of it, or just copy and paste it into your config management class to have it distributed. Chances are you want to use git in those workflows to get the agent from me. And now you have the shellout agent tagging along for the ride.

Future state: I have renamed the main repository to just be the yum repo and split the other agent into a separate repository so they can be managed independently. As of today you can get them at the following github links (though old urls will continue to work):

Yum: https://github.com/slaney/mcollective-yum-agent
Shellout: https://github.com/slaney/mcollective-shellout-agent

I am planning a post on my justification of the maligned Shellout agent in the very near future, so please come back.

iTunes “Helper”

I have a bluetooth headset I like. I use it at night sitting on the sofa messing around on my laptop to listen to music or videos on YouTube. However one annoyance I have always had with them is that when I connect to them they would launch iTunes.

So I googled around a bit and noticed that there was an app called iTunesHelper that was part of my Login Items. I removed it from there, and that seemed to do the trick, at first.

After a few weeks I noticed the behavior came back. I was perplexed, until I realized iTunes must be restarting the helper when it was used. After a 2 second test I realized this was true. So I helped the helper.


# cd /Applications/iTunes.app/Contents/MacOS/
# sudo mv iTunesHelper.app iTunesHelper-shutup.app
# sudo pkill iTunesHelper

Ugh, done.