Some weeks back I wrote how old animosities within the committees developing an updated ZigBee specification (Smart Energy Profile 2.0 and associated IP-based protocol stack) were overflowing into public view. In April, a vote on the draft specification unexpectedly failed when a group of participants, nominally aligned with the traditional ZigBee adopters, rebelled against the specification of the widely used, but notoriously inefficient, HTTP/TCP protocol as the transport protocol, instead backing User Datagram Protocol (UDP) plus the new, but less taxing Constrained Application Profile (CoAP) protocol.

Like so many standards development soap operas – and there have been many – this battle was replete with ideological grandstanding, political intrigue, personal recriminations, and Washington-worthy spin doctoring. Most importantly, the stalemate threatened to continue to hold large-scale the Home Area Network (HAN) deployments hostage. Already, most of the large California utilities, who are now approaching critical mass of deployed HAN-enabled smart meter, are waiting for SEP 2.0 before rolling out HAN devices and the energy management programs they will enable.

It turns out that locking everyone in a room in Wuxi, China, in June led to an agreement allowing both solutions, defusing the battle and allowing the process to move forward. The revised specification was released on July 15 for public comment. Since people on both sides of this debate are genuinely smart and passionately committed to strong solutions, I can only assume they all enjoyed some good Chinese beer together afterward.

Normally, resolutions that result in “allow both and let the market decide” end badly, with the market confused and vendors paralyzed. But this is not like VHS vs. Betamax. Without glossing real technical issues, this debate was more over a technicality, as protocol proxies are able to provide interoperability between the approaches transparently. The issue stirred such passion because it served as a kind of proxy for the priorities of the different camps within the group, as described in my previous post.

But perhaps herein lie the risks. Last week I installed an AT&T 3G MicroCell in my home that enables decent in-house cell reception (AT&T has apparently given up providing good coverage in my area, offering this for free). In the “Things to Know” section of the installation guide, it states, “Like many devices, your 3G MicroCell and your 3G phone handset may occasionally need to be “rebooted” to reestablish their connection to each other.” This of course is completely consistent with my PC, smart phone, and Wi-Fi router experience. I was amused by this frank admission – and apparent acceptance – of this condition as normal. It then occurred to me that I will not be so amused if my HAN devices (water heater, HVAC system, smart appliances) will need to be occasionally rebooted.

For all its non-IP inelegance, the ZigBee PRO protocol stack on which the SEP 1.0 version is based, was crafted out of real-world, mission-important (if not mission-critical) applications involving hundreds of network nodes in a variety of commercial applications where reboots are not acceptable. The new IP-based versions still have to prove this level of reliability. It took two to three years for the original SEP 1.0 products to reach “deployment worthiness” (as defined by utility testing in Texas) after being officially certified by the ZigBee Alliance. The SEP 2.0 work will need to happen much faster, though it is not clear how it can.

So perhaps utilities that are waiting for SEP 2.0, comforted by the fact that it is now moving forward, should take a closer look at the updated SEP 1.1 version released this week, which provides some of the application level enhancements of SEP 2.0, but uses the existing, proven (but not IP-based) stacks. This may be a good interim step toward the ultimate SEP 2.0 deployments.

There remains a risk that dual tracks within the ZigBee specifications (SEP 1.x vs. SEP 2.x) will lead to market bifurcation and higher devices costs due to the necessity to support both. Certainly the staunch IP proponents continue to grumble that this is an end run by traditional ZigBee vendors around SEP 2.0. But these vendors generally have SEP 2.0 implementation ready to roll too, and have been testing them for months. They lose only if the stalemate continues. If the IP-ification of ZigBee is truly worth all the market delays that it has caused, then these benefits should quickly become evident in the products and applications it enables. I believe it will, but in the meantime, there are good, robust, standards-based solutions available today to start true HAN deployments.

Then, perhaps, ZigBee will stop being the technology everyone loves to hate.

Earlier this month, Tendril Networks and Siemens Energy, Inc. announced a strategic alliance to market the Tendril Connect platform to utilities. Tendril Connect, the core of Tendril’s home energy management offering, is one of the most comprehensive home energy management solutions available. The Siemens partnership could do big things for Tendril by connecting it with a new set of potential utility customers.

With its Tendril Connect platform, Tendril is aiming to get into the home for the benefit of both the utility and the consumer. It consists of a suite of energy management applications that will not just collect and analyze data but enable remote control of home systems on behalf of the utility and the consumer. The platform will enable personal energy use visualization, demand response, load control, energy efficiency, electric vehicle charging, and on-site renewable energy integration.

With deregulation and competitive retail electricity markets on the rise in the United States and abroad, Tendril is also setting its sights on competitive electricity suppliers by offering customized services that will match customers with the best suppliers and pricing plans given their energy usage behaviors.

Siemens, by virtue of its deep presence in the U.S. utility sector and its project management and implementation capabilities, is in a position to take Tendril’s technology to the next level. Tendril already counts over 30 utilities as customers, ranging from small municipal utilities to major investor-owned utilities such as SCE, ComEd, and National Grid and competitive suppliers such as Reliant and Green Mountain. Through its partnership with Siemens, Tendril will be on the fast track to landing new customers with larger footprints and, with any luck, selling them more fully-fledged versions of its platform.

In addition to augmenting these existing utility relationships, Siemens’ venture capital wing, SVC, will help sharpen Tendril’s market strategies and support its financial and operational planning efforts. The size of SVC’s investment into Tendril was not disclosed, however.

In the United States, the near-term path to success for home energy management players will be through partnerships with utilities. In other countries, such as the United Kingdom, home energy management companies such as AlertMe and PassivSystems are making a play by selling straight to the consumer. While Tendril’s long-term ambitions are international, it’s focusing on the United States today, and its partnership with Siemens will help cement the relationships it needs to expand its uptake in the United States.

Sometimes it seems that ZigBee is the technology everyone loves to hate.

Born circa 2002 out of the desire for a standard for the elusive “Internet of Things”, ZigBee is a set of specifications using the IEEE 802.15.4 radio standard for connecting “things” ranging from home devices (light switches, thermostats, appliances, etc.) to industrial and building controls.  Though the ZigBee standards process included the usual technical arguments, politics, and bickering, it ultimately resulted in a low cost, self-healing, low power (i.e., battery operated) and scalable (i.e. thousands of nodes) technology. ZigBee includes both a mesh “network stack” and “application profiles” that specify the messages used in specific applications (home automation, building automation, etc.).

During ZigBee’s development, a fateful decision was made to NOT use the Internet Protocol suite. This seemed a rational decision at the time: max packet sizes are far smaller (127 vs. 1500+), there was no IP mesh specification, no concept of battery-conserving “sleeping nodes”, and the 15.4 radio silicon had extremely constrained memory.  These constraints led ZigBee engineers to eschew the overhead of IP’s layered architecture, and they set out to “build something that actually worked”.  While most “IP engineers”, noting the power of the internet, saw this choice as just plain stupid, few worked to address the Internet-of-Things challenge.  No small amount of professional (and sometimes personal) enmity emerged between these groups.  (Full disclosure: I was a marketing executive with the leading ZigBee firm in 2007 and 2008.)

When the smart grid community began looking for a Home Area Network (HAN) solution, they latched onto ZigBee as the only viable, mature, multi-vendor solution available.  They worked quickly to develop the “ZigBee Smart Energy Profile (SEP)” for HAN applications.  Today, tens of millions of smart meters are deployed in Texas and California based on this initial specification.

However, the failure of ZigBee to leverage IP emerged as a critical flaw.  ZigBee emerged as a vertically integrated set of solutions that was difficult to connect the IP-based outside world without resorting to application-specific gateways, and was also difficult to adapt the application profiles to other protocols such as HomePlug and Wi-Fi. In contrast, at least theoretically, IP’s layering allows translation between lower layers of the protocol stack while keeping the application layers transparent.

When the NIST standards efforts got turbocharged in 2009 by ARRA stimulus funding, the obvious benefits of IP’s layering, combined with good politicking, led NIST to essentially mandate the use of IP-based protocols.  Additionally, the 6loWPAN specification emerged from the IETF describing how IP packets could be squeezed into small 15.4 frames.  Many claimed a more powerful IP-based alternative to ZigBee could be developed in a smaller memory footprint.  The ZigBee Alliance had no choice but to agree to an IP-based ZigBee standards rebuild.  Smart engineers from both groups began earnestly working together to develop a new standards suite, nominally called “Smart Energy Profile (SEP) 2.0”. The reconciled groups made fast progress against impossibly aggressive deadlines.

However, this April a draft SEP 2.0 ballot failed, causing old animosities to resurface.  At issue is the choice of transport layer protocols: TCP and HTTP as is typical in today’s internet, or UDP and CoAP (Constrained Application Profile) protocols.  TCP/HTTP is notoriously inefficient in terms of bandwidth and end-node processing (witness generations of “TCP offload engines” in server network adapters), while UDP/CoAP is simpler, but new, unproven, and hence obviously not in widespread use.  While nuanced technical pros and cons exist, the heart of the matter is broader and has potentially serious industry implications.

ZigBee is most often implemented in “systems-on-chip (SoC)” that combine a processor, radio, memory, and other functions into a single low-cost chip.  Fitting the ZigBee software into these constrained devices was a concern even before the move towards IP.  Despite optimism that IP-based code would be smaller, current draft implementations are significantly larger, and TCP/HTTP in particular stresses the RAM capacity in these devices.  This potentially threatens the upgradeability of millions of ZigBee-enabled meters and devices already deployed.  For ZigBee SoC vendors and their customers, this is a serious concern.  For others, forcing a new, though more efficient, protocol is too much to ask if ubiquitous protocols already exist, even if it fundamentally challenges existing hardware.  And here enters the politics….

The TCP/HTTP advocates (roughly equal to the original IP proponents) charge that the UDP/CoAP advocates (roughly equal to the original ZigBee proponents) are deliberately stalling SEP 2.0 in order to force the industry to lock-in their original ZigBee solutions (SEP 1.x) for upcoming HAN rollouts.  The UDP/CoAP folks counter that they just want a more scalable solution and protect existing investments. Besides, they say they already have SEP 2.0 solutions available, so there is no advantage to a delay.  They claim the installed base is not being taken seriously, and some technology vendors that lost the initial HAN selections, such as Wi-Fi, might benefit if existing ZigBee installations were rendered obsolete.   So there are many possible political motivations surrounding this ostensibly technical disagreement.

In the meantime, utilities and their suppliers are largely caught in the middle.  If they have not been paying close attention, they should start.  Even if UDP/CoAP is a technical kludge, it has happened before in support of existing installed bases – just look at PPP-over-Ethernet, a spec that allows use of dial-up modem protocols over Ethernet and ATM-based DSL links.  There is nothing particularly elegant about this, yet it allowed an easier carrier infrastructure transition from dial-up internet access to today’s ubiquitous broadband.

The worst possible outcome will be a stalemate adding to HAN technology deployment delays.  Unfortunately, this appears to be the most likely outcome, and contributes to our relatively pessimistic view of near-term HAN adoption. 

One of the fun parts of being analyst is participating in many of the smart grid conferences around the world. These events are invaluable for meeting face-to-face with the leading utilities, technologists, and regulatory leaders in the various regions. While the PowerPoint is always appropriately focused on the vision and promise of smart grid implementations, the reality emerges in the back-and-forth discussions and personal networking that accompanies these events.

One series of conferences that I have particularly enjoyed over the last year have been the Smart Grid Technology Conferences developed by Smart Grid Update. At the risk of shameless self-promotion, I’ve been privileged to chair these events in San Diego and London, and will do so again in San Jose on June 1 and 2. (Note: Pike Research has no commercial interest in these events.) These events are unique in that in addition to individual presentations from leaders with real-world implementation experience, there are a series of highly interactive panels that aim at avoiding what I call the “lemming syndrome,” consisting of panels with a series of generic presentations followed by a brief Q&A session where each panelist takes five minutes each to essentially say, “I agree,” to a generic question.

Instead, at these conferences we aim to dive right into a discussion with the panelists (dispensing with any PowerPoint) and invite direct participation from the audience. And because these conferences have been relatively small with high-quality attendees, these discussions have been engaging, informative, and fun. Unlike larger conferences with competing break-out sessions, the audience stays together for two days, allowing greater opportunity for relationship building and networking.

The topics for this year’s conference line up well with the issues we at Pike have identified as the most important for smart grid in 2011: Communications, Data Management, Cyber Security, Standards Development, Distribution Automation, Demand Response evolution, and Home Energy Management. You can get a flavor for some of the discussion here.

Of course, there are many other good conferences out there as well. So if you are interested in getting a jump on the true state of the smart grid, get out and join in the fun at a conference of your choice. Chances are, you won’t be sorry.