OpenHAB tricks for the Aeotec Zwave Doorbell

The Aeotec Zwave Doorbell

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 stable main
deb testing main
deb 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"
    Item rules_house_doorbell_mute received command
    if (receivedCommand == ON) {
      sendCommand(zwave_house_doorbell_volume, 10)
    } else if (receivedCommand == OFF) {
      sendCommand(zwave_house_doorbell_volume, 0)

Trying it out

Screen Shot 2016-02-17 at 12.30.45 AM
Doorbell Controls OpenHAB UI

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.

Fixing Verizon DSL’s incorrect DNS response behavior

TL;DR unbreak macports on a Verizon DSL connection by replacing the last octet of your Verizon DNS servers with .14 to disable redirects to a search page for domains which fail to resolve.

Over the holiday break I had reason to update macports on my venerable old laptop, and apparently it was the first time since moving to the new house which is currently served only by Verizon DSL. During the process I got a really unintuitive error in several packages that followed the form:

Error: Failed to configure poppler, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/poppler-0.29.0/config.log

Error: org.macports.configure for port poppler returned: configure failure: command execution failed
Please see the log file for port poppler for details:

Starting to debug the problem, I noticed that several of the ports had only empty directories where tarball contents should have been. Then I noticed this gem in the logs:

Warning: Your DNS servers incorrectly claim to know the address of nonexistent hosts. This may cause checksum mismatches for some ports. See this page for more information:

Yep. That’s the problem. Fortunately Verizon lets you opt out of this behavior it calls Search Assist, but which breaks internet standards.

I’ll save you some painful wandering through the site (it tries to lead you through based on modem and firmware version, but didn’t have mine) and just tell you all you have to do is replace the last octet of your Verizon DNS servers with .14 to disable redirects to a search page for domains which fail to resolve.

If you have DNS X.Y.Z.12 just change it to X.Y.Z.14. Done.

Then follow the instructions at the macorts MisbehavingServers for any port that seems to be broken or just plain wonky and everything should be back on track. I had a broken version of autoconf and gawk in my tree, so pretty much nothing worked, making the issue obvious, but if it had been some dependency deep in the build I might have stumbled around for hours.