When we bought our house it didn’t have a doorbell. I hadn’t consciously considered the utility of a doorbell, but the house is in a cell phone dead zone so the lack of a doorbell has left guests cooling their heels waiting for us to notice their arrival, or frantic knocking if we’re downstairs. Some first-time visitors end up wandering around wondering if they’re even in the right place.

As a result, one of the more practical items I picked up in a recent run of home automation tinkering was the Aeotec Gen5 Zwave doorbell. It plugged neatly into a wall socket, that until the doorbell arrived, had seemed oddly placed being high up on the wall over our stairs. The doorbell remote connects to the base unit over a proprietary radio protocol, but the base station speaks the wireless zwave protocol that can connect to many smart home base stations. I had rolled my own base station from a RaspberryPi and an Aeotec Z-Stick Gen5 using the free OpenHAB software. Once the doorbell was paired into the zwave network I laid plans of incorporating the doorbell into my setup to make this one smarter than the average doorbell.

OpenHAB Setup

First I had to get OpenHAB talking to the new device. This section assumes you are already somewhat familiar with OpenHAB and administration of Linux packages with apt-get.

Hopefully this part will be much simpler in the future and can just be ignored, but as I was setting this system up the OpenHAB project was in the midst of its transition from 1.x to 2.x versions such that 1.x versions were no longer being actively built and released, while 2.x versions were not yet ready for production use. My challenge was that the the Aeotec doorbell had been added to the top-of-tree zwave binding’s zwave product database after the last official builds posted to the OpenHAB .deb repository.

To work around this issue I started out by pointing apt-get to the latest builds of OpenHAB and updating my RaspberryPi to the latest 1.x version of OpenHAB (which was version1.8.1 at the time this was written).

deb http://dl.bintray.com/openhab/apt-repo stable main
deb http://dl.bintray.com/openhab/apt-repo testing main
deb http://dl.bintray.com/openhab/apt-repo unstable main

sudo apt-get upgrade openhab-runtime/testing

Then it was off to find a build of the zwave binding I could get working with this setup. In the end I was able to download .jar build of a recent successful build of the top-of-tree version 1.9 zwave binding from a Jenkins continuous integration server either here or here. Installing the .jar file in my OpenHAB addons folder allowed the binding to find the device, but attempting to configure the device via the HABmin zwave binding web interface ended up crashing the OpenHAB server every time. So… don’t do that. Just look up the doorbells zwave node id and code up any items and bindings as needed. Those seemed to work just fine.

Items and Rules

With the doorbell recognized by OpenHAB it was time to bind some items and start automating this sucker. My main motivation was to control the volume of the doorbell to effectively mute it when we didn’t want an audible notification. A bonus would be to instead push a notification to our cellphones, but that will have to wait for a later post.

I started by aiming for just manually controlling the volume and ended up with the following lines added to my OpenHAB items configuration file. When the ON payload is sent with theSWITCH_BINARY command it triggers the doorbell chime to play just like a press on the outside button, which is useful for testing. The doorbell is zwave node 4 on my network, you should replace that in the bindings below with the correct node for your network.

Switch zwave_house_doorbell "Doorbell" { zwave="4:command=SWITCH_BINARY" }
Number zwave_house_doorbell_volume "Doorbell Volume [%d]" { zwave="4:command=configuration,parameter=8" }
Switch rules_house_doorbell_mute "Doorbell Mute"

The second binding is for the doorbell’s volume. I looked up the zwave configuration information for the doorbell on Pepper, a clearinghouse for zwave device info, and found that the volume is configuration parameter 8. OpenHAB has a virtual command that lets you set configuration parameters. So by using a Number item and binding to the CONFIGUATION command using parameter 8 we’ve got an item which controls the volume on a scale from 0 to 10.

Finally, I added a Switch item to act as the mute button. This item has no direct zwave binding, instead this switch is used to control an OpenHAB rule that toggles the doorbell between 0 (no sound) and 10 (max volume).

rule "Doorbell Muter"
  when
    Item rules_house_doorbell_mute received command
  then
    if (receivedCommand == ON) {
      sendCommand(zwave_house_doorbell_volume, 10)
    } else if (receivedCommand == OFF) {
      sendCommand(zwave_house_doorbell_volume, 0)
    }
end

Trying it out

At this point you’ll want to go ahead and add the three items above to your home’s OpenHAB sitemap and give it a try. You should see something like this in your default-themed OpenHAB web UI.

You’ll note that the Doorbell Mute doesn’t immediately update the UI for the Doorbell Volume. This is because the Volume item gets updated directly from the doorbell device itself. We could probably us the postUpdate() command in our muting rule to cause the UI to update immediately, but this way you can be sure that the value in the UI is being read from the device itself.