Christoph and I have been working on automating a few things at openBerlin, a Cisco innovation center. In particular, they have office spaces with banks of lights in them but no wall switches or controls. Instead, a non-optimal Web page allows people to change the brightness and colour of the lamps in the offices, assuming they know which office they’re sitting in and which lamp is “theirs”. As openBerlin has a number of iBeacons located around the office, we thought we could pimp OwnTracks in such a way as that a person could whip out their smartphone and, at the click of a button, switch the lamp they are sitting under. To cut a long story short, it works.

What we actually do is related to iBeacons in the office in that a beacon transition event (e.g. “JP is entering the proximity of beacon #47”) allows us to know which beacon a user is closest to, and as there are lots of beacons, we can associate a beacon with a lamp, and therefore know where somebody is sitting. So far so good, but how do we provide a “click here to control your lamp”?

featured content

The OwnTracks iOS app has a new tab which is shown when it receives a particular MQTT message of type cmd.

{"action": "action", "content": "Click here:", "_type": "cmd"}

That tab disappears if content is omitted, hence with an enter event we show the tab, and with a leave event we can hide the tab.

We were then able to load a page which allows a user to click to be directed to a page to switch or dim the lamp they are closest to. (In the openBerlin infrastructure, this means talking to a REST api which actually then control the lights.)

When we told Ben about this, he asked how we talk to openHAB. I was a little stumped because this has nothing to do with openHAB, but I then thought: hey, why not? We discussed this a bit and Ben suggested creating individual openHAB sitemaps with one switch each and then load those as pages.

openhab sitemap

Within minutes, Christoph had the OwnTracks app using the alternate url instead of content, and that allowed us to load a page into the application’s tab:

{"action": "action", "url": "", "_type": "cmd"}

One thing led to another, and my resident openHAB consultant tought me a few new tricks, in particular, that I can configure a switch to have multiple bindings on it, for example an actual Zwave switch which can be triggered with an MQTT publish to lights/zn/cmd and which retains the switch’s current status at the topic lights/zn/status:

Switch Zn "Zn plug" (Lights,gSunset) {

So, an MQTT publish will switch the lamp on or off:

mosquitto_pub -t lights/zn/cmd -m ON

The result is a jQuery mobile page loaded by OwnTracks which speaks MQTT over Websockets to the MQTT broker openHAB is configured to use.

Light control

This new OwnTracks feature works well, and I could imagine people will find plenty of uses for it with or without iBeacons.

Getting back to the beginning of this story, what we’re really doing is throwing technology at the fact that the building’s architect omitted wall switches; that is something I wouldn’t have done.

OwnTracks, iBeacons, and automation :: 15 Feb 2016 :: e-mail