I just got back from WaveForum in San Diego, and what a worth while trip! I went with the intention to solidify my requirements and design for the wireless sensors I want to use in the Wovyn project. I spent a good bit of time ramping up on Zigbee, XBee, and other wireless solutions – point to point and mesh. I can now see that the market still needs to evolve quite a ways …
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!