HouseControl plugin architecture

I have now restructured by HouseControl (previously known as ORControl) Java software.

It now has a plugin architecture. This means that all control of devices and other features is implemented by a plugin. Each plugin has a defined interface and is a dynamically loaded Java class. This means that any plugin can can be swapped out and a different implementation chosen. All this is controlled by the XML configuration file.

This makes it very easy to support different products and technologies. For example if you are using Z-Wave devices rather than LightwaveRF devices, you can swap the LightwaveRF plugin for a Z-Wave one. (Not that I have a Z-Wave one yet). Similarly if you don’t want to use Google mail for your email sender, you can implement a new Java class for a different email system. Similarly for the calendar and for COSM. If you don’t want to log your power and energy data to COSM, you can implement a different data logging plugin.

Each plugin can support multiple interfaces, so, for example, the LightwaveRF plugin in supports the LightControl, SocketControl and SwitchControl interfaces.

This is all functional, but the design has not been finalised yet.

In particular, I have not decided what granularity to do the configuration at. For example, should I support multiple products or technologies for each device? So, should I allow some sockets to be LightwaveRF and some to be Z-Wave, and configure this for each socket? I suspect I should, but I have not implemented this yet.

Another design decision is whether to treat sockets, pluggable sockets, and individual appliance monitors as the same or different types of device. Currently I have a SocketControl interface and an ApplianceControl interface. The only difference is that the appliance interface allows the power from individual sockets to be queried. The fact that some devices are wired in as wall sockets and some can be plugged in and out, does not really seem to affect the functionality or the way things are configured.

If I change to a single interface for sockets and appliances, then I already have two technologies for sockets, so will need to configure things at the individual socket/appliance level.

Incidentally, I now have one double LightWaveRF wall socket installed, and two more on order. I also bought two more EDF IAMs. This means that I will have 14 switchable sockets/appliances, and a total of 15 LightWaveRF devices, and 5 EDF IAMs. There is still a long way to go before all lights, sockets, appliance and windows/doors are controllable.

The Java source is not in Github yet, but it should be ready soon.

This entry was posted in Home automation and tagged , , , , , . Bookmark the permalink.

2 Responses to HouseControl plugin architecture

  1. richard says:

    Soumds very interesting.. please let me know when you have it up there for download 🙂

    • Geek Grandad says:

      Hi Richard, The first version of HouseControl is now available at I have started writing a series of tutorials on how to use it. This is a very early alpha version, with known bugs, a lack of error checking, poor code and other problems, but it does work for me, and I hope that it will evolve into something that others can use.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s