I’m not sure where this thread is going. Are people
suggesting that we eliminate the simple DR information representations that are
currently in the OpenADR specifcation? I can certainly understand why some
people would prefer not to use them which is why the current OpenADR
specification does not dictate that they be used. In my
lifetime I've built and deployed numerous versions of embedded gateways and
building management systems for precisely the type of utility applications we
are trying to address in both the residential and C&I space. I've led
development efforts where we spent millions of dollars engineering SOC's in
order to bring down the BOM of such devices so that we could deploy them in
massive quantities. My point is that I think I understand how important it is to
support low cost intelligent controllers in buildings that communicate with a
utility's headend in such a way that supports what Michel and Toby have described
and I would never support a standard that does not support that model. That
being said, in terms of a standard, what is more important is that we recognize
that there are a lot of different ways to skin a cat and we should support an
exchange of information that supports options for how systems are deployed both
now and in the future.
I’d like to reiterate that the simple representations in the
OpenADR spec are sent in conjunction with and not instead of the other DR
signal representations and it is not required that they be used. There is
nothing in the current OpenADR spec that precludes anyone from doing precisely
what Michel and Toby have described with whatever type of device you might
imagine regardless of the BOM. What the alternate representations do
allow is for a variety of approaches to be taken by the end user to consume DR
signals and it is an option that is left open to the end user to decide.
If in fact people are suggesting that we eliminate those representations
then in essence we will be narrowing the end user’s options and dictate
to them that they consume the DR signals in a more constrained fashion than
what is currently in the OpenADR spec. The bottom line is that given that there
is overwhelming evidence in the current OpenADR deployments that the simplified
representations are extremely useful for a wide variety of reasons I would not
support eliminating them, especially since their presence does not preclude any
of the various models I have seen described in this thread.
As suggested, lets add this as an agenda item for our next call.
-ed koch
From: Michel Kohanim
[mailto:]
Sent: Thursday, December 03, 2009 9:10 PM
To:
Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
Hi Rish,
This is precisely what we are not saying: “super computer
may solve all our computing problems”.
What we are saying is that almost any small footprint
hardware/firmware solution can address OpenADR specs including WS Calendar.
With kind regards,
********************************
Michel
Kohanim, C.E.O
Universal
Devices, Inc.
(p)
818.631.0333
(f)
818.436.0702
http://www.universal-devices.com
********************************
From: Girish Ghatikar
[mailto:]
Sent: Thursday, December 03, 2009 7:23 PM
To:
Cc:
Subject: Re: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
Michel,
I agree that RTP would simplify many problems that are barrier to DR participation.
However, implementation of systems and other related actions (e.g., programming
costs) for this requires understanding buildings, strategies, and the systems
that exist currently (with or without retrofits) and those that may come in
future. It also requires customer adoption and migration, which takes time. We
can say a super computer may solve all our computing problems, however, the key
question here is -- can everyone afford it and if they can, what would it cost
to operate and maintain it?
Thank you,
-Rish
Michel Kohanim wrote:
Hi Rish,
