Several months ago, I began working on the Shion iPhone client for Shion 2. The original plan was to create an iPhone client using the XMPP infrastructure that I had been building and release it early this summer. During this process, I ran into a number of challenges that prompted me to return to the desktop Shion codebase and begin renovating the core application. What began as a simple minor update to the app quickly ballooned into a massive reworking of the core application. In retrospect, this was exactly the right move.
While I will describe the iPhone app in a future post, this post discusses the major changes from Shion 2 to Shion 3.
The Shion Framework
The Shion Framework is an open-source library that I’ve been writing for the past couple of years that serves as the driver layer between the Shion application and the variety of home automation technologies that I support. When I committed to a major rewrite of the Shion program, the Framework was the first thing that I tackled.
The Shion Framework began as a simple library for communicating with the PowerLinc 2414U INSTEON USB controller. Over time, I expanded the framework to communicate with other controllers and technologies. In 2009, I added support for the CM11A and CM15A X10 controllers, and in 2010, I began supporting the INSTEON SmartLinc and SimpleHomeNet EZServe networked controllers. As I added support for each additional controller, the Framework codebase grew in size and complexity. During the Shion 3 rewrite, I revisited the Framework to consolidate much of the source code and to add hooks for features that were missing.
So, whereas in the previous version, each controller had their own subroutines for handling X10 and INSTEON messages, the new version uses better object-oriented design to eliminate the duplicate code. Another reoccurring problem with the Framework was the tendency for controllers to lock-up & quit responding. The Framework now includes functionality to detect controller issues and respond to them accordingly. In my own work with the PowerLinc 2412 (a new controller that Shion 3 supports), this feature has drastically improved the performance and uptime of my local INSTEON networks.
The rearchitecting of the Framework anticipates the eventual support of ZWave and other home automation technologies. It’s now much simpler and efficient for me to add support for new controllers as the need arises. Where it originally took me about 2 weeks to add support for a new controller under the older Framework, I can now begin supporting new controllers in a couple of days. (Hardware documentation permitting, of course.) Similarly, I’ll be able to add non-home automation devices quickly to the mix as well. Currently, Shion supports the Apple USB modem for Caller ID listening, but I plan to add support for cameras, Bluetooth devices, and other hardware that isn’t explicitly designed to work in an existing home automation framework.
Overall, on the hardware side of Shion 3, you will see a much more robust & efficient system for communicating with your controller & devices of choice.
The User Interface
When I began writing Shion in the 1.x days, I had a handful of INSTEON & X10 modules and the flat list user interface reflects that simplicity. Over the past year, I have drastically increased the number of devices in my own environments and struggled with quickly sorting and navigating through them.
Shion 3 fixes this problem by adopting a tree-based browser view that organizes devices based upon their platform, type, location, and other factors. By moving from a list to a tree, dealing with more devices has become much more convenient. Furthermore, in addition to the tree navigation, I’ve also implemented a history view that allows you to review a device’s state over the past week or more. This ability to look back has been invaluable as it allows me to notice when I’m having problems with my network and begin observing my patterns of device usage. I will talk a bit more about the philosophical and theoretical underpinnings of this feature in a later post, but now that I have the history available, I cannot go back to the old way of doing things.
Using the tree structure that I originally designed for the devices, I went ahead and consolidated the mess of windows that were present in Shion 2. Alongside your devices, snapshots and triggers appear and are treated in the same way. You can assign categories to both and navigate using those as aids. For those new to Shion, a snapshot is the saved state of the devices that can be recalled later. Triggers are the same things as events were in Shion 2. You can define a trigger to match a particular set of conditions and the trigger is fired when those conditions are met. Some examples are
- The time is 9:46am on Monday, Wednesday, or Friday.
- The temperature rises above 77 degrees.
- A B10 ON X10 command is heard on the local network.
- It’s 30 minutes before sunrise.
When one of these conditions are met, the trigger fires and takes its defined action. These actions can be activating a snapshot or running an AppleScript.
Under the Shion 2, displaying and editing triggers and snapshots brought up their own windows. In the new system, they’re all part of the main Console window. As the application grows, I’ll continue to consolidate as much as possible into this one window.
The Business Model
I’ve mentioned the new Shion business model to folks over e-mail, but I don’t think I’ve made it completely explicit here on the weblog. Moving forward with Shion 3, there will be no more license codes or need to purchase the desktop software. I am making Shion 3 free (as in beer) for anyone who wants to use it. Similarly, I will also be making the mobile applications and other interfaces to the software free as well.
To support the continued development of Shion, I am building a proprietary online service that connects Shion on your desktop to Shion on your iPhone (or other device). If you would like an iPhone interface, you will need to subscribe to the online service. If you don’t care for an interface beyond that which is already on your machine (or wish to build your own using the AppleScript interface), you won’t need to send me a single cent.
I am adopting this new business model for a couple of reasons:
- Subscription models are generally better for a business’s month-to-month income.
- Selling Shion as a one-off product of its own at $35 didn’t work out too well.
- I have a variety of new features to add to the platform that really only make sense in an online service context. No online service, no nifty new features.
I am not ready to announce any pricing details at the moment (the system’s still under construction), but I will be reaching out to existing users in the next couple of months to try and find a “sweet spot” that works for end-users while allowing me to continue to fund the development of the platform.
The Next Steps
Over the next several weeks, I’ll release different components of the Shion 3 platform as I have them ready. Later today, I’m releasing an alpha version of Shion 3 for interested testers. In a week or so, I’ll start contacting existing Shion users about participating in the online service & iPhone beta test.
While I’ve been using Shion 3 for almost 2 month now, I want to caution you that it’s still very much an unfinished product. There are still bugs in the system and parts that are still unimplemented. However, by releasing this earlier (than later), I’m hoping to jumpstart a feedback loop that will help me shape this into a product that works well for more users than just myself. If I can find enough vocal beta testers, I’m confident that we can come out of beta at the end of the summer.
Thank you for your continued patience and I look forward to writing more about Shion 3 in the weeks ahead.
Recent Comments