opnode panTastic: architecture of a new server controller

I must admit that I slightly abandoned my opnode project long time before starting the panStamp project. After more than five years, opnode has not gotten the popularity that I initially expected, surely due to the cost of the custom hardware. Opn-max is the only opnode relying on a low-cost third-party (Linksys) hardware platform and people still seems reluctant to do the jump – hacking the Linksys NSLU2 has resulted a bit complicated for non Linux users.

Figure 1: opn-max controller running on a Linksys NSLU2

This said, I've planed to revolution the opnode project since I started this blog. I see lots of synergies between opnode and panStamp, maybe not for simple wireless networks but most people wants to integrate different technologies nowadays, and that is exactly the goal of the opnode project: piping different communication technologies into a common IP integration platform. The old opnode architecture has resulted to work efficiently and fast. However, the “one gateway per cloud” paradigm is a bit costly and not very popular in the Home Automation area. Instead, most people prefers to invest in more powerful hardware capable to work as a multi-port gateway or controller. At least, this is what I've learned from the opnode community.

Figure 2: old “one gateway per cloud” paradigm

Coming from the Industrial world, I'm a big fan of isolating networks and tasks through the use of independent gateways. However, I understand that Home Automation hobbyists prefer to take such decision themselves. On the other hand maintaining a single plural project instead of several vertical ones seems that will simplify my life a little. All these factors have led me to conceive a new opnode, panTastic, a controller with all the features provided by opn-max plus the possibility to add support for different communication technologies into a common box.

Since the current opnode software was exactly tuned to follow the old paradigm, panTastic will need a new architecture, something really open to the addition of new communication ports and protocols without having to rebuild the whole application along each addition. Moreover, I want this project to be as much programming language independent as possible, at least regarding the development of plugins (or clients). As result, I've configured a new architecture where the main core (panTastic server) dialogues with multiple communication clients. Each client is then the responsible to maintain the necessary communication tasks with each wireless cloud or bus field.

Figure 3: panTastic architecture

Flexibility is maybe one of the main features of such architecture. Anyone can decide whether to integrate multiple communication technologies or not, place the client inside or outside the server box or simply develop the client using any programming language capable to work with TCP/IP sockets. As for the hardware, panTastic will work on any 32-bit platform capable to run Java ME, SQLite, Perl, PHP and LightHttp. In other words, almost any cheap x86 platform such as the ShevaPlug or any of the eBoxes should be able to run panTastic without problems.

Regarding the integrability of panTastic, this project will let us do many things with our wireless PAN's:

• Maintain different PAN's (SWAP-based or not) from one or multiple panTastic controllers.
• Use the IP LAN as a common communication trunk for different panTastic controllers and thus for different PAN's.
• Program events and scripts for each PAN or bus field.
• Monitor and control endpoints from any web browser.
• Generate and display Web charts based on data stored in the SQLite database.
• Integrate wireless and wired clouds into other remote software applications via xAP BSC or custom TCP/IP (opn-max, Mr House, HomeSeer, HAL, MainLobby, etc).

In summary, panTastic will bring new possibilities to SWAP networks, providing a good degree of smartness, even to clouds formed by very simple motes.