Shion Online

After putting out the 3.2.1 update last night, I turned my attention to a problem that’s been vexing me for well over a year. For those of you using the Shion Online service and accompanying iPhone app, the reliability of the service has been a persistent issue.

On the server side of things, the root of the problem has been an issue with the Java-based Openfire XMPP server taking up way too memory and getting into trouble once it exhausted the available system RAM. I put into place scheduled jobs for killing and restarting the process to clean up periodically, but the memory use would skyrocket after a short period.

Last night, I looked more into the problem and ran across a thread on the Openfire forums describing a memory leak associated with the Personal Eventing Protocol (PEP, a.k.a. XEP-163) that sounded exactly like the situation I’d been experiencing. I applied a suggested fix and the server load time has been reduced back to where I thought it should have always been.

I’m extremely pleased that this solution has worked out so far. If it continues to hold (and I’ll be watching over the next week), it removes the need for me to continue with the planned rearchitecting of the Shion network functionality and resume working on improving the stability and functionality of the various applications.

If you’re a user of the online service and can confirm my observations from your perspective (the service is snappier and more reliable), I’d appreciate it.

Happy holidays everyone!

First of all, I owe every Shion user an apology for my absence for the past year. In a nutshell, my consulting business took on a good amount of work, and it’s only been recently that I’ve been able to fulfill those obligations and clear them off of my agenda so that I could resume work on Shion and my other projects. Due to personal reasons, I’ve largely shuttered my consulting business and am now working as a 9-to-5 employee doing much of the same things I did as a consultant.

With the change in my employment situation, the Shion project is changing as well. Instead of trying to develop the application into a commercial product, I am open-sourcing the code and work will continue as an open project. This frees me from having to make technical decisions dependent upon commercial considerations, and allows me to take the project in a direction that makes the most sense from a technology and innovation perspective.

I’ve received a few queries over e-mail about Shion 3 and support for custom web interfaces in light of the impending release of the Shion online service later this summer. I’ve responded over e-mail, but figured that I should post some comments here as well.

First of all, to give some background, the scenario I’m addressing is one where a Shion user creates a custom set of PHP pages (or web framework of choice) that they host on a local machine (running Shion) to expose a web interface for devices like an iPad. Mr Flibble, a UK-based Shion user, has done exactly that.

I want to state unequivocally that I have no problem with Shion 3 users deciding to create their own web interfaces in lieu of subscribing to the Shion online service. Shion 3 will continue to support the AppleScript functionality that is used to bridge the Objective-C & PHP worlds. I can’t (technologically) prevent such third party activities without completely ditching the scripting functionality, which I am unwilling to do for a variety of reasons.

Furthermore, I respect the do-it-yourself ethos of the home automation community. Given that the typical member of the current home automation community is pretty technologically savvy, they’re going to build their web interface somehow. I’d rather that they build upon my platform and send me comments about my application instead of submitting that precious feedback to a competitor. The Shion platform is still in its early phases, and I can use all of the comments and suggestions that I can get. 🙂

So, if anyone will be allowed to create their own free Shion 3 web interface, how do I plan on competing with a subscription-based online service? Several ways:

1. Simplicity & reliability: Setting up Shion and a client to connect to each other is simply a matter of entering a username and password. There’s no need to mess with system settings to configure ports, set up and maintain a web server for serving the pages, or worry about forwarding ports and maintaining a dynamic DNS name for use outside your home.
2. Rich client support: The native Shion clients on mobile platforms will include features and functionality that are simply not present in web interfaces. This includes efficient two-way real-time communication between Shion nodes, location awareness, and AI-assisted user interfaces that learn to present you with an optimal interface based upon location, time of day, and other factors.
3. Ubiquitous client support: As I’ve mentioned before, my goal is to display a Shion user interface on any device or medium that will support it. Mobile phones and Internet-capable portable devices are the first targets on the list, but I have plans to support Shion on your television, e-book reader, instant messaging client, digital picture frame, and so on. Traditional Web interfaces are nice (and the Shion online service will include one as well), but there are many more options for control that have remained largely untapped by the current crop of home automation developers.

These are admittedly some grand goals, but perfectly attainable over the next year or so. My task is not only to think about optimal web interfaces, but also to think beyond web interfaces to create an environment where users can monitor and control their environments independent of the presence of a web browser. My belief is that as I bring more of these interfaces online, a sufficient number of users will recognize the value provided by being a Shion subscriber to make this a sustainable enterprise.