As I look at what they are doing, there are things that I really like about their goals, and design … and there are things that I think are limiting.  What it really does is validates the work we are doing with Wovyn!

Great Goals

The goals that I really like about Twine are the end-user “ease of use” and simplicity.  This is a must in any product like this.  There is a lot of technology built into the Twine solution, and if done right they will end up hiding a lot of that complexity from end-users and software developers.

I also really like the “rules” system, Spool,  that they demonstrate in their video.  Rule systems that can handle events, and allow developers to create simple to complex rule sets for dealing with the events from sensors are a critical aspect of the “Internet of Things”.  It’s not enough to simply connect “things” to the Internet, and not enough to have those things “speak”.  The “Internet of Things” will become truly useful when there are plug-and-play rule sets for taking in combinations of events, and causing actions ranging from notifications to actual control of other “things”.

Twine Limitations

Not to disrespect the work that has been done with Twine, I do want to comment on a few things that are not clear to me right now.

1. Internal Sensors – it appears that the Twine unit contains a limited number of internal sensors, and maybe has a way to add one (or more?) external wired sensors.  From my experience this is a severe limitation.  I know that I want dozens of sensors, and they have to be spread throughout my home.  I know that wired sensors are not going to work for this, and so I’m not clear on how Twine will support (and at what cost?) an installation spread across a larger physical space, and requiring 20, 50, or 100 sensors.
2. Open support for various “Internet of Things” platforms.  I see where the Twine product will talk with Spool, but will it also be able to talk with other REST services, Pachube, or use other protocols like MQTT?  Again … I believe this is key to the success of products in this industry.  As developers begin to incorporate these types of products into their solutions, I believe this will be a critical aspect for success.

I can only sit here impressed with Twine, and look forward to seeing them be successful with their KickStarter project … I do believe this will demonstrate the validity of the market!

Early in the LAN days, there were so many different networking technologies that looked promising – Corvus Omninet looked promising as it competed against the high price of Ethernet which was being pushed by 3Com.  Not too many people realize that IBM at the time was pouring millions of dollars into Token Ring.  ARCnet was also hugely popular at this time due to it’s ease of installation and operation.  These were only some of the variety of network technologies competing in the late 1970′s, 1980′s, and towards the 1990′s.

One of the most revolutionary things that Novell did at this time is to embrace their “Open Protocol Technology” approach to networking.  Although incorrectly naming their software a “bridge” the solution was truly revolutionary at the time.  Novell created a routing abstraction that allowed them to mix and match network types and topologies in the same network and server.  Instead of locking a customer into a single network topology, Novell’s NetWare operating system and enviromentment allowed their customers to start with any networking technology, and add or migrate to any other seamlessly.

Evolution in the Internet of Things

Right now I believe we are witnessing the same evolution in the Internet of Things.  With Wovyn we are planning to address two very different sides of our design with a similar approach.

Our core platform will be supporting numerous wireless sensor platforms.  Our first will be a proprietary 900Mhz wireless solution that provides a good variety of sensor types, low-power operation, and good distance.  We are also designing the platform to allow for other types of sensors – both wired and wireless – to be added.  We are experimetning with one-wire still, and also Zigbee/XBee mesh wireless sensors.  Our goal is to ensure that our architecture does not lock our custromers into a single sensor technology or topology.

Our platform will also be supporting numerous data communications protocols.  We are already compiling the list, but the sensor data will be able to be posted natively to our own Wovyn platform, but also to Pachube, MQTT, iDigi (if we can!), any REST platform, and the other “Interent of Things” data aggregation platforms that are showing up on the market.  What this means is that a software developer can invest in our product, and know they can have their data easily integrate into what ever platform they choose to use.

At this point in time for anyone investing in the “Internet of Things” an extensible architecture is a must … lock-in at this point will surely cause headaches in the future!

Ease of Installation

One of the most frustrating things about this market is the end-user configuration.  For the Internet of Things to become adopted and ubiquitous it must be simple to install and get working.  What I am finding is that people have not really thought through the actual applications – and the required installation and set-up tasks – and what end-users will experience.  As we move forward designing Wovyn, one of our core criteria is to make it simple for software developers to install the Wovyn product, easily configure it to connect to the Internet, and then easily configure it to begin posting data to their applications.

Wireless Sensor Configuration

One thing that I am convinced of is that the sensor network we are creating must be wireless!  Over the years I have worked with so many data acquisition cards, one-wire sensors, and other solutions … but it’s just not enough.  I want to be able to spread small sensors all over my home, business, or commercial location (or even outdoors) and have them work without having to string wires all over the place.  Although Wifi is good, I also believe that alternate frequencies and protocols have advantages over trying to create Wifi sensors.  Cost is one of the big issues.  Configuration is the other.  When I go to add sensors to my wireless sensor network, it has to be plug-and-play … add the sensor, power it up, have it join my network, define the details about the sensor, and then define the rules of what I want to occur when sensor data or alarms are reported.  Also … I’ve got to be able to easily monitor the battery level in the remote sensor so that I can know when to change the battery.  All of these are design criteria that we are incorporating into Wovyn.

Support for Numerous Protocols and Platforms

The last thing that I realized at WaveForum is that Wovyn cannot be tied to only our platform … or to only one other platform … but be open to report data and alarms into multiple platforms.  At the WaveForum conference Digi was touting their own iDigi platform extensively, but there are many other solutions coming on the market.  One such platform is Pachube that has gained ground quickly in the developer market.  Pachube provides REST web services for posting, and subscribing to device data.  In addition, IBM has released specifications for it’s MQTT protocol, which is an efficient way to push data into applications from embedded devices.  As we move forward with Wovyn, our design is to be a multiple protocol solution … not locking users into only our platform, but allow them to easily configure support for the diversity of platforms that are appearing on the market.

Wovyn is coming … and the design is solidifying!

For the last two decades or so, I moved away from hardware, and heavily into the realm of the Internet, and have been working mostly in the area of Internet and Mobile applications.  But over the last two years I have been watching as the capabilities of various chip sets and embedded controllers has continued to grow.  With the introduction of the Arduino and Netduino platforms … I was interested in moving back into hardware.

About the same time I came across some wireless sensor technologies that I realized could be an amazing source of data for a wide range of projects.  A friend of mine and I talked about ways to instrument bee hives, and as I looked for solutions I found a platform that could provide some revolutionary capabilities.  My goal is to create a low-cost wireless sensor network that is connected to the Internet through a gateway that leverages Wifi in any home or business.  It will have the ability to report sensor measurements, and also generate events based on threshold that can generate events into other systems.  All of this built on a SaaS platform with open APIs.

Wovyn was born.  Stay tuned!