I was planning to answer a question in a comment on previous post and wanted to talk about the number of xPL clients that I have running. Rather than just quoting the number, I thought I'd make a post to put my response in context.

Most of my xPL components support the hbeat schema. So I can identify them by sending a hbeat.request message. My perl xpl-sender command can do this:

bash$ xpl-sender --schema hbeat.request --wait 10

By default, the sender just sends the specified message and exits. But, with the --wait parameter, it prepares to receive replies, sends the message and waits the specified number of seconds for any replies. The output from the above command is a summary of each received hbeat.app reply:

xpl-stat/hbeat.app: bnz-apcups.apc -> * 5/53556/192.168.32.1
xpl-stat/hbeat.app: bnz-blue.slave -> * 5/51540/192.168.32.1
xpl-stat/hbeat.app: bnz-ccost.slave -> * 5/58435/192.168.32.1
xpl-stat/hbeat.app: bnz-dmx.slave -> * 5/44072/192.168.32.1
xpl-stat/hbeat.app: bnz-gpower.slave -> * 5/59772/192.168.32.1
xpl-stat/hbeat.app: bnz-heyu.slave -> * 5/56009/192.168.32.1
xpl-stat/hbeat.app: bnz-lcdproc.slave -> * 5/41722/192.168.32.1
xpl-stat/hbeat.app: bnz-linux.slave -> * 5/46917/192.168.32.1
xpl-stat/hbeat.app: bnz-lirc.slave -> * 5/33992/192.168.32.1
xpl-stat/hbeat.app: bnz-mpd.slave -> * 5/32798/192.168.32.1
xpl-stat/hbeat.app: bnz-ownet.slave -> * 5/46631/192.168.32.1
xpl-stat/hbeat.app: bnz-rfxcomrx.slave -> * 5/40448/192.168.32.1
xpl-stat/hbeat.app: bnz-rfxcomtx.slave -> * 5/48635/192.168.32.1
xpl-stat/hbeat.app: bnz-sendsms.slave -> * 5/47592/192.168.32.1
xpl-stat/hbeat.app: bnz-smart.slave -> * 5/43472/192.168.32.1
xpl-stat/hbeat.app: bnz-udin.slave1 -> * 5/50553/192.168.32.1
xpl-stat/hbeat.app: bnz-udin.slave2 -> * 5/52187/192.168.32.1
xpl-stat/hbeat.app: bnz-wol.slave -> * 5/33981/192.168.32.1
xpl-stat/hbeat.app: bnz-zenah.slave -> * 5/39324/192.168.32.1
xpl-stat/hbeat.app: bnz-mythtv.vz -> * 5/34473/192.168.32.6
xpl-stat/hbeat.app: bnz-smart.vz -> * 5/34298/192.168.32.6
xpl-stat/hbeat.app: bnz-xosd.vz -> * 5/34487/192.168.32.6
xpl-stat/hbeat.app: bnz-xvkbd.vz -> * 5/49051/192.168.32.6

Each summary is of the form:

message_type/schema: source-identifier -> target interval/port/ip

and each source-identifier is of the form:

vendorid-deviceid.instanceid

My vendor id (developer id) is bnz, the device id is typically the type of the device being managed, and the instance id is typically the hostname of the machine running the client.

There are two machines in the list vz (which is my main mythtv box) and slave (which is the main home automation server). (The observant may notice that there is also apc but that is actually running on slave monitoring an APC UPS via USB but the instance id is changed as a convinience in order to distinguish between slave and the UPS as they both report power/battery information.) The clients on the mythtv box are:

• xpl-mythtv which reports the percentage utilisation of the video inputs/tuners,

• xpl-smart which reports disk temperatures so I can turn on fans to extract warm air from the server room,

• xpl-xosd which responds to osd.basic schema messages showing on-screen display text using xosd, and

• xpl-xvkbd which sends fake key presses to the active window (probably a security risk even though the keys always go to mythfrontend).

The clients on slave are:

• xpl-apcups which reports status of my APC UPS and sends events if when the UPS switches between mains and battery and vice versa,

• xpl-blue which monitors for the presence of various bluetooth devices so that my house "knows" when different people are home,

• xpl-ccost which monitors my mains power usage (or at least it did until it got confusing when I started exporting power) and the solar power generated by the PV panels on my roof,

• xpl-dmx which sends commands to a Milford Instruments DMX Transmitter to control a Pulsar ChromaZone 12 Controller which in turn drives a number of ChromaRange lamps,

• xpl-gpower which reports my power usage information into the Google PowerMeter API,

• xpl-heyu which uses the heyu X10 software control my mains appliances and lights,

• xpl-jabber which enables interaction via XMPP instant messages (such as Google Talk),

• xpl-lcdproc which responds to osd.basic schema messages showing text on a picoLCD-4x20-slideshow device using the [lcdproc][] protocol,

• xpl-linux which reports Linux battery status and events, system temperature, etc.,

• xpl-lirc which reports LIRC IR remote button presses (so that I can switch the kettle on or send wake-on-lan packets using a basic TV remote control),

• xpl-mpd which controls a Music Player Daemon to play music in several zones around the house,

• xpl-ownet which is an interface to an OWFS Daemon that reads from temperature/humidity sensors and writes to relay controllers on the one-wire network in my house,

• xpl-rfxcomrx which is an interface to an RFXCOM RF Receiver that reports RF messages received from various sensors, switches, etc.,

• xpl-rfxcomtx which sends RF messages via an RFXCOM RF Transmitter to control X10, HomeEasy, etc. devices,

• xpl-sendsms which sends SMS messages via any service supported by the SMS::Send Perl API (I use the service from Connection Software),

• xpl-smart which reports disk temperatures,

• two instances of xpl-udin to control two UDIN USB Relay Controllers to momentarily pulse the open/close inputs of several blind and curtains,

• xpl-wol which sends wake-on-lan packets (using the etherwake command) to wake up devices that are shutdown in order to save power (such as my mythtv box), and

• zenah which is the brains of my house - triggering actions based on timers and incoming xPL messages.

I am also running several other clients that run in stealth mode - that is only sending messages and not listening for or responding to hbeat.request messages. These "inputs" include:

• a web frontend,

• an experimental daemon supporting the lightswitch API so that I can use existing Android (or iPhone) applications to control my house, and

• some security-related inputs (that I wont be writing much about).

I'm currently trying to refactor the code to separate out the device-related code from the xPL code and to reduce the coupling between the web interface and the zenah "brains". This will probably involve a couple re-write of the zenah component and the web interface.

In my previous post, I mentioned some of the issues I was experiencing with my current choice of home automation protocol, xPL.

The primary issue was the need to perform filtering for every message on every client due to the use of broadcasts for messaging. One way to avoid this is to use a pub/sub messaging system instead. A number of people that I respect have been using the MQTT Protocol so I thought I'd take a better look at it.

I figured a good way to understand it would be to implement it. I've implemented several protocols from scratch without any documentation so implementing MQTT from a well-written specification was simple process. The basic implementation took less than a week and resulted in Net::MQTT and AnyEvent::MQTT on CPAN.

The protocol is lightweight and flexible. This is great. It works well in contexts where you are both publisher and subscriber because you can design the simplest, minimal messaging format between agents.

However, building communities that can write components that can interoperate will require some more structure. For example, using xPL, I have a client that monitors messages using the "sensor.basic" schema and creates/updates round robin database files for each sensor reading. This works for all xPL clients that support the "sensor.basic" schema regardless of developer/platform/etc. Another good example of this kind of protocol layering is XMPP and the XMPP Extension Protocols.

Essentially what is required to make this work is an ontology - a specification for topic usage and semantics. I have no idea how to produce such a suitable ontology but I plan to think about it some more. I'll probably draw ideas from various existing sources such as xPL Message Schema, xAP Message Schema, Pachube feed definitions, etc.

If anyone has any ideas (is it a good idea, how to proceed, etc?) then I'd love to hear about them.