When the phone rings in my small office, Frizzix tells me instantaneously who’s calling, and I can decide whether to take the call or not. (I usually do, because few people phone me.) It’s a nice utility, but I can neither automate it nor can I easily save the call logs, and doing that from the FritzBox Web interface is a nuisance. And when I’m not at home, I’m blissfully unaware that somebody called, but curious nonetheless. I was curious whether I could be notified of calls in “real-time”.
My initial experiments with openHAB have been fruitful, and with a bit of help in understanding some of the more intricate combinations, I’m progressing in automating the Intranet of Things at Casa Mens.
openHAB has a FritzBox binding (there’s also an Asterisk counterpart) which I can use to trigger switches on incoming calls. This binding updates an openHAB item when it detects a call on the FritzBox, useful for, say, automatically muting the Sonos when the phone rings. This item definition looks like this:
That item definition suffices for openHAB to detect an incoming log, which it shows in its log:
If I place that item on an openHAB sitemap I can see the Caller-ID (CID) on the UI (which I don’t want), but what else can I do with that trigger?
- detect an incoming call with the FritzBox binding
- invoke a rule with that CID number
- perform an external lookup on the number to obtain a matching name from my address book
- store the result in a database
- publish the result to an MQTT topic
and the answer is a resounding YES!
When the incoming call triggers the
Call switch, openHAB invokes this rule I
patiently assembled with a lot of trial and error, and error, and help from the
knowledgeable chaps on the mailing-list.
The rule gets the calling number (which may be empty if a caller suppresses it) and executes an external command. (I’d be weary of having openHAB do that on a very busy “trigger”, but it’s not an issue in this case; I don’t get many phone calls… ;-) This little program does a reverse lookup on my address book database, and it returns a string with the number and a name in parentheses.
(Note the binding supplies an empty caller on anonymous calls, and both values are empty when the call ends.)
The rule then posts an update to another openHAB item, this time a String item
This item is bound to an MQTT publish string which causes openHAB to publish the value to my MQTT broker. From there, believe it or not, the Caller-ID is pushed to my mobile phone. (How that works is a longish story :-)
There is one thing missing from my five-point checklist above: I wanted the result persisted to a database, trivial to accomplish in my small Python program, but that’s no fun!
As mentioned in my last post I can configure openHAB to persist any state updates and changes to different storages, including a built-in db4o database, rrd files, etc. I chose to use a MySQL database to keep track of a few values including callers.
Persistence is configured on a per/item basis in a
Resulting from this configuration, I find the following tables in the database:
I wouldn’t put frequently-changing states in MySQL, rather relying on, say, rrd for things like that, but for my use-case this is perfect.
The WAF for this is pretty good, but the Señora doesn’t appreciate the notifications whilst en casa. It ought to be easy to add an openHAB switch item which disables notifications to MQTT (and hence onto her mobile device) when she’s at home. And we can automate that presence detection with the binding for OwnTracks (formerly MQTTitude).
Using MQTT you can effectively decouple all notifications from within openHAB. This means you no longer need to load the Mail, Twitter, Prowl, NMA, or XBMC action bundles, and you can replace all your notification rules with very simple one-line statements