Advanced Telemetry CTO

Final Post

2011-08-23T09:21:00.000-07:00

Somebody once told me that the only thing that stays the same in this life is change itself. So true.

On August 15, 2011 Advanced Telemetry was sold to Siemens Building Technologies (SBT). I am staying on as Director of Cloud Computing for SBT and will continue to contribute to the development of the EcoView product as well as explore new applications for cloud services within the organization. Details of the acquisition can be found here.

This blog will be shut down sometime in the next few weeks or months. I have, however, started a new one: The Cloud Line. The new blog will be centered around general cloud computing topics and technologies and will not focus on the EcoView product at all.

Thanks to all of you that have followed this blog and taken an interest in Advanced Telemetry and the EcoView product line. It was a fun ride and the product will now take advantage of a much more capable marketing and distribution infrastructure. Siemens Building Technologies is a very forward-thinking company with great plans for the EcoView product. It will be exciting to watch.

-Tom

We've Been Blogged!

2011-03-21T14:03:00.000-07:00

Like many, I find the evolution of social networking to be an endlessly fascinating aspect of modern society. In particular, I think it is interesting how social networking intersects with business and influences the growth of technology-based industries. I am not sure that everyone would agree with a taxonomy where the blog is a first-class member of the social networking landscape (my kids for instance couldn't point to a blog if their lives depended upon it, but they do know all about Facebook, Twitter, etc.) but for me the blog is still an important player in the overall structure and trajectory of the social networking evolution.

Last week I got to experience a new aspect of social networking experience - being blogged about. Now, I cannot be certain that Advanced Telemetry (or me personally) hasn't been blogged about previously, but this is certainly the first time that I have been aware of it. The blogger in this case is Microsoft technical architect David Chou. David has been a huge help to me over the past couple of years as I have migrated the Advanced Telemetry product architecture to the Windows Azure platform. David is just one of those guys that seems tirelessly motivated and always ready to offer assistance and advice when it comes to cloud computing topics. For my money he is definitely emerging as one of the thought-leaders in cloud computing and has authored many highly insightful technical papers and articles.

David was largely responsible for introducing the Advanced Telemetry story to Microsoft and has been an advocate and supporter from the first time he came to visit us here in San Diego. His recent blog posting is really an overview of a couple of case studies and other press coverage that we have received from Microsoft over the past 6 months or so. He did a great job of putting it together and it is definitely worth a read. You can find it at the following link:

http://blogs.msdn.com/b/dachou/archive/2011/03/14/cloud-optimized-architecture-and-advanced-telemetry.aspx

Chipping away at my 15 mins of fame...

2011-03-02T16:33:00.000-08:00

Last year I had the great fortune to be invited to participate in a Microsoft SDR (Software Design Review) event in Redmond, WA. The focus of the review was the Microsoft cloud computing platform known as Windows Azure. As mentioned in previous posts, we are an early adopter of the Azure platform and moved all of our middleware and web applications into Azure early last year.

As a strong proponent of cloud computing in general, as well as the convergence of cloud computing and intelligent device networks in particular, I was absolutely thrilled and honored to participate in the Azure SDR process. This is an invitation-only club and only about 50 people from all over the world get to attend. Due to my NDA with Microsoft I cannot name names, but suffice it to say that there some real heavyweights from some of the biggest companies in the world in this little crowd - not to mention some of the more famous Microsoft personalities known to geeks like me worldwide. The 2 SDR events that I have attended so far have proven to be some of the most rewarding professional development experiences that I have yet encountered.

Late in January of this year I attended my second Azure SDR event and at one point during the 4 day session I was interviewed by the Microsoft technical media team known as Channel 9. This was a great experience as well and yesterday they published the interview along with a case study about Advanced Telemetry. Now, let me say that I was coming down with a head cold and as a result my voice was a little raspy. Whats more, I have done precious few on-camera interviews in my career and, as you will see, the lack of experience clearly shows.

Anyway, I thought it might be of interest to some of the folks that follow my blog but have never met me.

For some reason the video format is a little goofy on the case study link, so for a better version of the video alone you can go right to the Channel 9 outlet here:
http://channel9.msdn.com/Shows/Inside+Out/Building-on-Azure-Advanced-Telemetry

The whole case study and video (upper right corner) can be accessed here:

http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000009076

Enjoy.

It's Been A While...

2011-03-02T11:41:00.000-08:00

To the small handful of folks out there that bother to follow by blog, I do apologize for the long hiatus but in my own defense I must say that there was at least a partial justification for it. In late fall of last year we entered into discussions with a large building automation equipment manufacturer to license and private label our energy management product, EcoView. At the time we were expecting to have the deal done by mid Q4 and my next blog post was to announce the change. Alas, big company processes and the inevitable delays they impose prevailed and the deal was not done until Feb 1 of this year (2011).

It turns out that getting the deal done does not entitle me to publish the name of our new OEM license partner, however, which means that I cannot reveal the name of this Fortune 100 company as part of this blog post. Anyone who follows the consolidation of the building automation market over the past few years will know that there are only a small handful of large, international players left and, until I am given the green light to publicize the name, I will have to leave you to guess at which one it is.

So what does this mean for Advanced Telemetry and the EcoView product? It means that our highly innovative and market leading product, EcoView Commercial, will now be distributed by one of the biggest corporations on the planet. EcoView, it seems, has graduated into the mainstream market for energy management products and our license partner will be able to open the market in ways that we could only dream of previous to this. Their reach, sterling brand reputation and global footprint will give the EcoView product a new level of exposure and accessibility. I could not be more excited by this opportunity.

Expect to see some public announcements sometime soon as well as updates to our website that will reflect the change in distribution. Our new OEM partner has exclusive, worldwide distribution rights so over the coming months there will be a gradual transition for processes such as submitting orders and requesting support. In the meanwhile, we are still here and able to eliminate any friction in the transition process.

As soon as I am able I will post again with more details about this change.

The Power of the Platform

2010-10-14T16:36:00.000-07:00

First of all let me say that for all 3 of you that follow my blog, I am sorry for the gap since my last post. I have been largely occupied as of late with activities surrounding our latest funding round as well as handling a couple of new opportunities that are of a sort that only I can deal with. These fall in the category of "platform sales" or sometimes "private label" opportunities and my experiences with these have inspired this blog post.

One thing about the EcoView EMS product that few people know or appreciate is that it is built on top of a telemetry platform that was originally architected and developed ahead of any real product concepts such as EcoView. My original vision was to develop a platform that could support a wide range of telemetry applications and featured a local touchscreen user interface that doubled as the telemetry gateway device. The server system middleware was designed to support any remote monitoring and control application and as a result has very few intrinsic data types and no expectations in terms of the types of devices that could be controlled and monitored.

A tremendous amount of work has gone into the core platform, internally known as the TAF (Telemetry Application Framework) over the past 7 years and it has evolved along with the needs of applications such as the GE Ecodashboard, the Breezeplay residential energy management product and, most recently, our own branded energy management product known as EcoView. In fact, many more development hours have gone into the TAF than have gone into any of the application variants - including EcoView. This may be surprising to some, seeing as how EcoView is our primary product and the focus of our marketing efforts.Products such as EcoView, however, represent the thinnest possible layer on top of the TAF technology stack. Moving forward, we are looking to extend our market reach by pursuing many other vertical applications that the TAF is ideally suited for. Examples include back-up generators, refrigeration equipment and pumping systems. Unitary equipment such as this would benefit greatly from the ability to remotely collect runtime data, generate alarms and provide real-time remote monitoring and control. The touchscreen UI is also of value since a laptop is ordinarily required to interface with machines of this sort and a permanent, full-color display would add convenience for local operators.As we head towards 2011 the emphasis on new vertical applications for the TAF will gain greater importance as well as focus for the company overal. Expect to see web site adjustments and marketing efforts aimed at exploiting the platform technology that, for today, lies hidden underneath of the EcoView EMS product line.

Try, try again...

2010-08-02T18:18:00.000-07:00

We've all heard it said: You just cant please everyone. Like most people I recognize the basic truth behind this statement - at least in the general sense. The struggle I often have, however, is in discerning when negative feedback from a customer warrants a re-think of some feature or service and when it is best to hold the line. This is the situation that we have been confronted with following the release of EcoView Web Commercial version 2.0.

As can be expected with any major product update, we have gotten a handful of complaints and criticisms about version 2.0 of our EcoView Web Commercial product, released in May of this year. This is our web-based application that allows customers to manage and configure commercial sites (restaurants, convenience stores, small offices, etc.) that have been outfitted with our EcoView Commercial energy management system. I've heard adjectives like clunky, confusing and, possibly worst of all, ".. an engineer's dream.." - ouch. In my own defense I have to say that the handful of customers that I was listening to when designing this version absolutely love the thing now that it is available. I will be the first to admit, however, that this probably isn't simply a case of not being able to please everyone. I do see where some users find the interface intimating and less than intuitive. The thing is, a lot of work and innovation went into making it look and feel exactly as it does - allow me to explain.

EcoView Web Commercial version 1.0 was the first release of our multi-site, energy management web application. It was pretty simple and lacked a lot of features that customers were expecting. Now in hindsight I have to admit that I never actually heard any serious complaints about the basic usability. Even so, it was clearly a version 1.0 effort and as such served admirably for the first full 2 years of the EcoView Commercial product evolution. The negative comment I did hear from a few of our key customers, however, related to EcoView Web being too "website-ish" and not enough like the more traditional energy management applications that they were used to. These "traditional" EMS applications, I will point out, are Windows desktop applications that you use from a single PC installed on the site somewhere. Since our primary user interface is web based, getting that desktop look and feel was a pretty big challenge. I think we got most of the way there with version 2.0 (see below screenshot).

This decidedly Windows desktop look was modeled after some of the more popular EMS applications that I have worked with over the years. You have a tree view on the left to select sites from, a dashboard in the middle to interact with selected sites and a property grid on the right to make adjustments to devices (thermostats, lighting, etc.). There are lots of other screens and features, including a very nifty graphing interface, but overall the general theme follows the same basic look and feel. Functional yes, sexy no. And, apparently, style counts for something after all - just ask Apple.

So I am sure you weren't expecting me to just cop to not quite meeting the mark with this product release and leave it at that. Indeed I have no intention of it. I am using this blog entry, rather, to announce that we have already began work on EcoView Web 3.0 and will be taking a decidedly different tact on this development exercise than was taken on our journey to version 2.0. For starters, we are going to be selecting several key customers to preview primary user-interface concepts prior to setting them in stone. This will take the form of a technology preview web site that selected users can poke at and give us feedback about what they think works and what doesn't. The obvious intent is to help us incorporate user feedback during the actual design and development phase rather than after the official release. What a concept eh?

Not to spoil the surprise for those users that will get a sneak-peak in the near future, but one of the key design concepts that we are exploring for the main user interface is a map-based site selector. For me this just makes perfect sense - rather than pick your sites from a list of some sort when you want to make adjustments or view current status, you select them from a map (think Google Maps) with pushpins representing your sites. This alleviates many of the problems associated with grouping sites when you have them spread across the country and also allows the pushpins to provide summary information to allow for quick review and assessment. It also just looks really, really cool. Sorry, no screenshots just yet but I really think that pretty much everyone will find this approach very intuitive and functional.

If you are a current customer that would like to participate in the EcoView Web Commercial 3.0 technology preview, please let your salesperson know about it and I will contact you to make the necessary arrangements. I'd like to get a few lovers and a few haters of version 2.0 to make sure that all points of view are represented in this.

One thing that I have learned over the years is that product development is subject to the same basic laws of natural selection that biology is. There is never a finished form, only ongoing evolution and adaption to changing needs. And so we take another shot at perhaps not pleasing everyone, but definitely achieving broader appeal for our customers and users of EcoView Web Commercial.

Apps, Apps Everywhere Apps

2010-07-12T17:22:00.000-07:00

In late Q2 of this year we were hard at work finalizing design elements related to the release of our EcoView Residential product when someone in the team suggested the concept of "Apps" for the touchscreen page set. Its not the first time that we have considered incorporating this popular paradigm into the residential product, but a set of circumstances related to supporting extended features such as weather, traffic, etc. led us to finally adopt this approach moving forward. We are currently set to release EcoView Residential on Sept 1 of this year and the production screen set will include an EcoView Apps page where future content will be available. Users will be able to log into the EcoView Residential web portal and select the Apps that they would like to have available. Apps are essentially software components that will be managed and delivered by our Internet server system.

Initially I saw little value in introducing the Apps concept into our EcoView Commercial screens but recently the idea has gained momentum and we are now working on adding this feature to our commercial product as well. Obviously Apps like weather, traffic, etc. have little appeal for a touchscreen located in a place of business, but a little brainstorming revealed at least one compelling App that would make sense in a restaurant, convenience store or retail shop. This first commercial App will consist of an employee time clock interface where employees can key-in their ID upon arriving at and leaving work. Our Internet server systems will record this data and make it available to management in the form of reports and down-loadable files. This is essentially an Internet-enabled version of the old mechanical punch-clock units that are still widely used today. We are currently vetting out at least one more App to introduce to our EcoView Commercial product - stay tuned for more details.

Much like Apps found in other products (i.e. smart phones), EcoView Apps will be consist of a mixture of free and paid add-on features. Some will simply be information displays, such as weather and traffic and some will be full blown independent applications such as the punch-clock App described above. In most, if not all, cases the product owner will be able to select which Apps are available at the touchscreen. This will be done through the associated product web portals.

I have included a mocked-up screenshot of the EcoView Residential Apps screen in this post. Note that the content providers shown are for concept/illustrative purposes only and do not represent Apps that are currently available as part of the EcoView product. In some cases commercial relationships with these providers are yet to be established.

Push vs. Pull - A look at EcoView Web 2.0

2010-06-02T10:46:00.000-07:00

Last month we officially launched version 2.0 of EcoView Web – Commercial Edition, our primary web-based user interface for managing and monitoring EcoView Commercial product installations. Initial customer reviews have been mixed. Some think it is far too “techy” and therefore not user-friendly and others think it is absolutely awesome. I can sympathize with those that find the UI to be too engineering-oriented since for many facilities managers and system operators this is their first encounter with an EMS user interface at all. In these cases parallels inevitably get drawn between EcoView Web 2.0 and much simpler web-based applications such as Gmail, etc. The simple fact here is that flexibility nearly always breeds complexity and EcoView Web 2.0 is no exception to the rule.

One aspect of EcoView Web 2.0 that was not very well supported in the version 1.0 is the ability to configure individual sites to automatically generate emails about issues rather than requiring a user to go looking for a problem by viewing graphs, etc. This was accomplished by providing user-configurable alerts based on pretty much any available data point as well as nearly limitless control over what points are controlled by schedule operations. The intent was to allow a user to essentially “wire up” a site to let him or her know if any point value ventures outside of a desired range. Even the acceptable range value itself can change during the day through the use of the new, highly flexible scheduler.

This “push vs. pull” approach was a major part of the original design requirements for version 2.0 of EcoView Web. Of course that is not to say that we skipped improvements to the “pull” capabilities of the application either. We added many new graph output types to enable performance visualization based on temperature, energy consumption and equipment run times. Even here, however, the intent was to provide these tools to not only assist with identifying problems to but also to help determine alert (i.e. “push”) trigger points and expected operating parameters.

All of this being said, we are certainly sensitive to making EcoView Web easier to use and more intuitive. It is clear that there is room for improvement in making alert rules and schedules in particular simpler to visualize and interact with. We also need to provide more template options, where specific configurations can more easily be applied to multiple devices and sites. These considerations are currently being fed into the design phase for EcoView Web 3.0 and our marketing group is going to be working with customers and end-users over the next month or so to get feedback on what works and what doesn’t in terms of the UI design. We are also planning to introduce an EcoView Web 3.0 technology preview web site where select customers can use and provide feedback on under-development design features to insure that user input is considered while still under development rather than after we are done.

Internet Thermostats ?

2010-05-14T13:10:00.000-07:00

Lately we seem to be running into customers that are in the process of evaluating our product against one of several Internet thermostat manufacturers. I guess this is a good sign in that it shows how small building owners/managers are waking up to the need for some sort of energy management equipment in their facilities. Its hard to see why anyone would settle for remote thermostat access alone, however, when products such as ours (EcoView) offer much richer energy management capabilities for around the same price.

I find this to be a somewhat curious device - the Internet thermostat. The concept is relatively simple: add an ethernet connection to a standard HVAC thermostat and be able to access it remotely. It sounds cool and all, and surely would have been 5 or 10 years ago, but as an energy management strategy I find it to be somewhat lacking. First of all there is the wiring headache. An internet thermostat will require new wiring since you have to get the thermostat connected to the internet. I am aware that some of them use WiFi, but few HVAC units provide enough power to support this alone, which means new wires for power. Second you end up with individual network devices that cannot really cooperate as part of a larger energy strategy - such as syncing schedules with lighting control or occupancy. You really dont have a "system" as much as you have a "device". Maybe its just me, but in this day and age this seems a little weak - kind of like needing mobile communications but opting for a pager over a cell phone just because it is a few dollars cheaper.

Products like EcoView offer the full benefits of an energy management system at a price point that is targeted at small building owners and managers. You get lighting control, HVAC control, equipment control, real-time and historical energy consumption data as well as nearly infinite expandability going forward. You also get both a local user interface (touchpanel) and web-based access - all in an affordable and easy-to-install package. The EcoView thermostats are direct replacements for pretty much any existing thermostat and as a result are very quick and easy to install. The only device that gets an internet connection is the touchpanel, which can be conveniently located close to the building telecommunications equipment for painless installation. The touchpanel also manages all network devices, as any good EMS product should, allowing cooperation and interaction in ways that are impossible with individual, internet-connected devices. The touchpanel of course also serves the useful purpose of providing a centralized user interface where all devices can be viewed and controlled without having to break out a PC.

Well, the intent of the post was not to bash internet thermostats necessarily, nor to shamelessly promote EcoView (okay, well a little), but rather to make the point that I think anyone smart enough to realize that they need to something about energy management in their small building or residence should look past substandard solutions and spend their money on something more comprehensive and extensible instead. EcoView is not the only product out there that meets this bill. The key, I think, is to invest in a 'system' rather than a 'device'.

My 2 cents.

Launching Into the Cloud

2010-04-12T15:13:00.000-07:00

If you’ve followed my previous blog posts, as well as the case study paper that Microsoft did on us late last year, you will know that we have been on a trajectory to migrate our existing server middleware and web UI applications to the Microsoft Azure cloud computing platform. I am happy to announce that as of late last week we now have a fully functional instance of our core middleware, system administration tools (web based) and end user web applications all running on Azure. This puts us pretty much right on schedule in terms of where we had hoped to be according to the original migration plan, though we did end up taking a somewhat different route than expected to get here.

The original plan was to migrate our existing core middleware components in an incremental, staged approach over the Q4 2009 – Q1 2010 time frame. This was to be done in a seamless fashion to avoid any interruptions of service for our existing customers while at the same time greatly expanding our functional capabilities by leveraging some of the key new service components available in the Azure framework. This plan proved to be quite problematic in practice. As it turned out, the move to Azure became increasingly complicated as we began attempting to engineer gap solutions to enable the smooth transition of a functioning system that customers depend on daily. In fact, it became clear to me in late February that this approach was having the effect of bogging down the effort to get to Azure overall. The bulk of our engineering resources involved in this effort were being devoted to the transitional strategy rather than actually focusing on adapting the core features of our system for the Azure platform. It became obvious that we needed to shift our strategy if we were going to move fully to Azure within any reasonable time frame.

The route that we ended up taking to was to simply take it on as an isolated task and one that did not include any incremental switch-over provisions or intermediary software solutions. The goal was to bring up a fully functional version of our middleware system in Azure with no real thought for the migration from our existing system. We simply broke down the functional components, interfaces and services and began replicating them while taking full advantage of the new technologies available in Azure such as table storage, BLOB storage, queues, service bus and worker roles. This turned out to be a very liberating experience and although we had already identified the basic design and architecture as part of the previous migration plan, we ended up making some key changes once unencumbered from the constraints inherent in the transitional strategy. The net result is that in approximately 6 weeks, with only 2 team members dedicated to it (yours truly included), we ended up fully replicating our existing system as a 100% Azure application. We were still able to reuse a large percentage of our existing code base and ended up keeping many of the database-driven functions encapsulated in stored procedures and triggers by leveraging SQL Azure.

The transition plan will now consist of enabling our web UI client applications to access customer data and services from either the new, Azure-based middleware system or from the existing, legacy system. New sites brought online will now be joined to the Azure system exclusively. Over the next few months we will slowly migrate existing sites by re-pointing them to the new Azure interface then follow up by backfilling all historical data associated with these sites into Azure table storage after the fact. While this is somewhat suboptimal due to the fact that there will inevitably be a gap in time between when a customer site is communicating with the Azure-based middleware and when all of the historical data has been transferred from the legacy system and fully available, the benefits of eliminating the more complex transitional strategy seem to more than offset this temporary inconvenience. It is expected that there will be no more than a day in between when the site is migrated and when all historical data is available via the web applications.

The fact that we ended up with a clean, stand-alone instance of our middleware and client applications that are in no way dependent upon or complicated by the previous system design has yet another benefit: easily enabling key customers to run their own unique server software and data storage instance. This is a request that we have received several times over the past few years and was not easily (or inexpensively) accommodated with our existing server application infrastructure. Now we can simply deploy a set of packages to a new Azure subscription and enable a unique server system instance with fully isolated data for large customers that desire (and are willing to pay for) this type of separation.

So far I can say that we are very impressed with the Azure cloud computing framework from Microsoft. Over the next few months we will be extending and refining our new Azure-based middleware system -watch for future blog posts that will summarize our experiences.

The Reverse Placebo Effect

2010-03-01T11:07:00.000-08:00

Something strange often happens, I've noticed, when you put an EMS product into a facility that didn't previously have one. Suddenly the slightest sense of discomfort, subjective as the concept of comfort is to begin with, becomes a cause for immediate complaint. We've seen it happen time and time again. The vast majority of these complaints are either entirely unverifiable or are ultimately traced to preexisting, long-term mechanical issues. So how is it then that simply installing the EMS triggers this kind of behavior from building occupants? This is the mystery that I have come to call the "Reverse Placebo Effect" (RPE) and it has the potential to become quite troublesome.

Occupants complaining to the head office about their work environment - be it a restaurant, convenience store or retail/office space - can derail otherwise successful projects with alarming speed. I recently had the maintenance director for a large chain of auto dealerships tell me quite unequivocally that the energy savings and many other benefits of the system wouldn't mean a thing if the senior management staff had to listen to disgruntled site managers. In this particular case we were able to identify numerous, long-standing mechanical issues that were the root of the complaints and these were then reported back to the customer for immediate action.

So what are we to make of this then? It seems to me that there are at least 2 major causes for RPE. The first is the simple fact that the site occupants no longer have the same level of control over their heating and cooling setpoints that they had with standard thermostats on the wall. Understandably, this often engenders a sense of lack of control that can be annoying and frustrating. For users of the EcoView system, we generally recommend allowing a comfort range of several degrees up or down that the occupants can work within. Since our system is centered around a touchscreen interface, the occupants can easily see the limits within which they are allowed to change setpoints. This goes a long way towards alleviating the sense of lost control but does not resolve issues with the mechanical systems, which are often what drives the occupants to fiddle with the comfort control settings regularly. It is also somewhat at odds with the general benefit of the EMS to begin with - which is to prevent local misuse of the mechanical systems that result in premature failure and unnecessarily high energy bills.

The second and closely related RPE contributor is the Big Brother problem. That is, the site occupants know that management is monitoring and governing their comfort and lighting settings and do not take kindly to being imposed upon by people that are sometimes thousands of miles away. Whats more, the occupants often assume that the energy consumption data, now at the fingertips of management, is being used to judge the operational efficiency of the local site overall. This is especially true for site managers, who typically are not aware of what they can do to conserve resources and as result feel that they are being unfairly judged on something that they cannot control.

Bringing EMS technology into the small building market for the first time has been a challenging endeavor to say the least. The technical hurdles involved in delivering a robust, cost-effective EMS product for this market have been at times daunting but over the past couple of years we have proven that it can indeed be done. Dealing with occupant issues is just another dimension in this challenge, albeit one that calls for a different type of solution. The most direct route for addressing spurious occupant complaints is clearly education. The site owners must be preconditioned to expect the low-grade initial backlash from site occupants. Site personnel, in turn, need to be assured that the goal of the system is not to sacrifice their comfort for the sake of energy savings. Additionally, during the initial installation (or preferably before the install) all mechanical equipment must be thoroughly inspected and tested. The site managers must also be interviewed to identify and document preexisting issues and a comprehensive report must be provided to the owners/managers very early-on in the project.

The good news is that in our experience the site complaints are generally short-lived. After approximately 30-60 days of living with the system the site personnel tend to become accustom to its presence and the incidence of complaints typically drop off dramatically after this point. Moreover, the system operators tend to make all necessary schedule and setpoint adjustments within this time period and preexisting mechanical issues get dealt with.

In my view RPE is an unavoidable reality and part of introducing an automation product into a market sector that is not familiar with it. Anticipating the effects of RPE is key in dealing with it effectively. It is clear that the benefits far outweigh the initial adjustment period and that site personnel can be trained to accept and appreciate the value of EMS in their buildings.

EMS for the home.... are we ready?

2010-02-06T16:11:00.000-08:00

This quarter Advanced Telemetry will be releasing its first residential version of the EcoView energy management product. This will not, however, be the first time our product will have been deployed in this venue (the home). Our private label distributors (GE Smart Commander, Breezeplay Enviroscene) have been at this for a while now with mixed success. We do get regular inquires from our commercial EcoView dealer-installers about the availability of a residential product and so last quarter (2009) we decided that we needed to accommodate these requests and launch and EcoView branded residential solution. This product was exposed to the world at the recent AHR tradeshow in Orlando.

Its definitely exciting to be releasing a new product, don't get me wrong, but in this case I have to admit to a certain amount of trepidation about getting back into the residential market directly. Ive been here before. My years at Coactive Networks, an early pioneer in residential device network gateways, were characterized by largish residential installations that we did in Sweden and here in the states with Enron, Detroit Edison and others. From personal experience I know that the home is an unforgiving environment for new technologies in general and homeowners tend to have high and/or unreasonable expectations for this type of product. All things considered, the residential market can be a real meat grinder, as the long list of failed companies that have attempted this market in the past clearly attest.

So what has changed to make me willing to get out there with our own branded product at this time? As it turns out, plenty. First of all, the device networking technologies, in particular wireless RF solutions, have matured considerably in recent years. At one time not too many years ago the only viable wireless technology was based on powerline communications, which presented a host of challenges that were difficult in some cases, if not impossible, to overcome. The new generation of wireless device technologies, including Zigbee and Z-Wave, appear to be much more reliable and straightforward to configure. Add to all of this the fact that residential broadband availablity and reliablity has improved markedly over the past few years and we may have a recipie here for large scale residential EMS rollouts after all.

Of course the growing public "green consciousness" doesn't hurt either. Anyone who has a TV knows that green is everywhere and personal responsibility for consumption of resources, in particular energy, has rapidly become a self-evident principle. Products like EcoView Residential enable behavioral modification in a way never before possible by displaying real-time and recent historical consumption trends in a convenient and attractively designed display unit.

And finally there is the cost factor. Through aggressive value engineering efforts we have achieved price points for basic residential EMS packages in the sub-$500 dollar range. In the end this might be the most important factor in stimulating the market for this type of product.

I guess time will tell how receptive the general public is to basic EMS products like EcoView Residential. Our distributors and dealer-installers will have to make the case to their residential customers that there is a sensible value proposition in this case. I have confidence that they will, at least to some degree, find success in this endeavor. Time will tell.

Clouds on the Horizon

2010-01-19T07:40:00.000-08:00

In spring of last year (2009) we realized that the vast amount of data being collected by our internet server system was quickly becoming unwieldy. After all, every sensor value change in our commercial installations and homes (temperatures, instantaneous power fluctuations, etc.) ends up recorded in our server middleware database. Additionally, a large number of health and site operational statistics are constantly streaming into our system from sites all over the country (soon to be international). Although we are constantly tuning database indexes and stored procedures in order to insure that all critical queries and operations are performed successfully, a traditional relational database has fundamental limitations in cases such as this. We we were rapidly facing a decision point; either make some serious infrastructure investments in database hardware/software or look to public cloud computing services for managing our growing data storage needs.

Initially we looked at Google Big Table and Amazon S3 services for offloading storage of historical sensor data (our largest storage need). These services utilize state-of the-art, non-relational storage technologies that are very attractive in terms of cost and anticipated performance. We also reviewed Microsoft Azure services and once we began to understand all that was available as part of the Azure framework all other choices quickly fell off of the table. Not only is the Azure framework much more comprehensive in terms of service components and features, the integration with our primary software development tool, Visual Studio, made Azure a no-brainer for us.

In the summer of last year (2009) we began migrating our server-based application components to the Azure framework. We started with our internal system management web applications and then moved on to version 2 of our primary end-user application for our commercial product, EcoView Web. Late in the year we began experimenting with techniques and approaches for offloading our sensor historical data - a process that is continuing as I write this blog entry. The tricky bit here is to seamlessly integrate the Azure table storage technology into a running system that processes nearly 100k sensor update transactions per hour.

The eventual goal is to migrate our entire server application to Azure. Though I had originally projected that we would complete this task by the end of Q1 2010, it is now clear that this is going to take quite a bit more time. This is because we dont want to simply relocate our application. Rather, we need to fully leverage the core services and features of the Azure framework, an effort that involves learning some new approaches and technologies. It is already clear, however, that this move will be extremely beneficial in terms of our long term ability to adapt and extend our server processes and application features.

It is clear to me that the future is indeed full of clouds. Cloud computing frameworks, especially Microsoft Azure, promise to completely change the landscape of internet-based services. The ability to leverage robust computational and data storage services in a cost effective and incremental fashion will no doubt lead to a host of entirely new applications.

If you are interested in learning more about our move to the Microsoft Azure cloud computing framework, click the below link to read the Microsoft case study that was put together in November.

Microsft Case Study: Advanced Telemetry

Wireless Woes and Wows

2010-01-12T17:02:00.001-08:00

As we are preparing to begin deployment of a handful of updates to our product line in the general area of the ZIgbee wireless device networking support, I have had a moment to reflect on our journey with wireless device networks over the past couple of years.

There can be little doubt that our product is dependent upon wireless device networking technologies. By far the largest number of installed sites, whether they be commercial buildings (restaurants, convenience stores, etc.) or residences, are preexisting structures where running new wiring is simply cost prohibitive. This reality simply mandates the use of some type of wireless device networking technology. Having had previous experience with power- line based technologies, we quickly discounted this approach due to transformer coupling issues that are present in nearly all small commercial buildings. This left radio frequency technologies and, again due to past experience, we selected Z-Wave as the basis for our initial EcoView product offering.

Z-Wave is a very robust and mature wireless mesh networking technology popular in home automation products. Very early on in our field installation experience, however, we found that the relatively low power output of the Z-Wave radios caused numerous issues for us. This was particularly true in restaurants where it is common to find a lot of stainless steel and other obstructions that often result in signal attenuation and loss of information. Nevertheless, we managed to install quite a few commercial facilities using Z-Wave and many of them still operate perfectly today (some have been switched to Zigbee).

This time last year (2009) we decided to try Zigbee radios to see if we would get any better performance in the field. We were attracted by the variety of Zigbee chipset vendors with competing features such as radio power choices and packaging options. Early tests showed that the additional radio power alone warranted seriously considering making the switch. In May of last year (2009) we launched the first version of our EcoView product utilizing Zigbee radios. This is where the fun started. We spent the next few months learning, painfully, about all of the Zigbee communication stack nuances and quirks and how they could come into play in real-world environments.

Particularly troublesome was the apparent tendency for the Zigbee wireless network to spontaneously decommission itself (nodes drop off). While this feature may be potentially interesting in some scenarios, such as where a device can physically move about, it was a real headache for stationary networks where sources of attenuation move instead, such as in commercial kitchens. This sort of issue was compounded by the fact that we currently purchase our HVAC thermostats from a private label vendor, who themselves struggled initially with the same wireless behaviors. Luckily, the initial trial-by-fire experience has smoothed out as our knowledge of the technology and its behaviors has matured. Sitting here now from the position of having several hundred installed sites working, it is clear to me that our product base is overall much better off for the move to Zigbee radios.

Happy New Year!

2010-01-04T13:20:00.000-08:00

As this is my first blog post I will keep it simple and light - I want to wish all of our customers and partners a happy new year. We at Advanced Telemetry are very excited about the product enhancements planned for this year. Stay tuned...