As a specific example, I have an older product that has
Python 2.3. To my definition, a simple client is one that is less than
200 LOC in Python 2.3 and uses SGML parsing.
I think a simple REST message is essential to low barrier
to entry. As seen on Twitter (forwarded more for humor more than serious
consideration):
Tim O'Reilly: @sramji in a
meeting: "The only reason you'd have only a SOAP API is because you hate
80% of your addressable market." REST FTW.
Original Message-----
From: Dave Watson [mailto:dwatson@lbl.gov]
Sent: Friday, December 04, 2009 2:38 PM
To: michel@universal-devices.com; energyinterop@lists.oasis-open.org
Subject: RE: RE: [energyinterop] Groups - DR Programs (DR-Program-DRRC_20090914
SK edits.doc) uploaded
As part of our research, LBNL interviewed programmers who
wrote code to
implement both smart clients (including control logic)
and simple clients
(include a few integers, no logic).
Research showed that programmers from multiple companies
using a variety of
programming platforms could consistently take a pseudo
code template from
LBNL, and create a simple software client application in
less than one hour.
I interviewed four programmers that wrote
"simple" software client code to
interface between their EMCS and the DRAS (circa
2005). The answers to
"time to complete task?" were: 1) 20 min. 2) 60
min. 3) 20 min. 4) less than
20 min. (not a measurable task).
The same question was asked of five "smart
client" programmers that wrote
code to interface between their EMCS and the "Price
Server" (circa 2003).
Since they were required to include logic and other
complexities the task
took from "weeks to months".
To keep the technical and economic bar to entry as low as
possible, we
should keep the simple client (or equal) in the
spec.
-Dave Watson
LBNL
Original Message-----
From: Michel Kohanim
[mailto:michel@universal-devices.com]
Sent: Friday, December 04, 2009 12:36 AM
To: energyinterop@lists.oasis-open.org
Subject: RE: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
Hi David,
What device does the conversation from IP to contact
closure? Can't the same
device support WS Calendar and Open ADR messages? If so,
then there's no
need for the simplified messages. If not, then I would
have to prove to you
that $20.00 devices can in fact do much more than what
you can imagine.
With kind regards,
********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.com
********************************
Original Message-----
From: David S. Watson [mailto:DWatson@lbl.gov]
Sent: Friday, December 04, 2009 12:27 AM
To: michel@universal-devices.com
Cc: energyinterop@lists.oasis-open.org
Subject: Re: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914 SK edits.doc) uploaded
The concept of the "simple" client evolved out
of 7+ years of Lawrence
Berkeley National Lab field tests in the C&I
sector.
Very early on we determined that the lack of a common,
simple interface to
existing facilities buildings was a major barrier to
recruitment and
participation in automated DR programs. The simple
client concept has two
critical features:
1) Well suited for contact closure (hardware interfaces)
or gateway
(software interfaces).
2) Allows ratepayer choice. They decide in advance
what it means for them
to do a "medium" or "high"
shed. They decide whether or not to use the
"event pending" (aka near or far) advanced
alert signals to pre-cool their
facility.
The most interoperable signal (by far) is dry contact
closures. Every EMCS
of every vintage can read digital inputs. With no
protocol conversions
necessary, one device (IP to contacts) will work for
virtually all sites.
This reduces not only BOM costs, but enables a DR program
to be deployed to
all customers with one simple interface device type.
None of the aforementioned features are precluded when a
subset of customers
use a more sophisticated interface. Research shows
that only 10-20% of
early adopters will have the capability to manage
software gateway
interfaces in the first few years. The general
population of existing
commercial buildings will be even less
adaptable.
In summary: We recommend leaving the so called
"simple" client (or equal) in
the standard, in addition to the "smart"
client.
Best regards,
Dave Watson
LBNL
In automated DR tests in 2005, (15) sites were
recruited. Of these,
(12) used simple clients and (3) used smart
clients. The introduction of
the simple client enabled virtually any site to
participate. It removed
barriers to recruitment.
Automated Critical Peak Pricing Field Tests: Program
Description and
Results, M.A. Piette et al., Lawrence Berkeley National
Laboratory, April
2006
The concept of the simple client or other means to enable
contact closure
interfaces to EMCS is imperative the wide-spread adoption
of automated DR.
-Dave Watson
LBNL
Original Message -----
From: Michel Kohanim <michel@universal-devices.com>
Date: Thursday, December 3, 2009 11:14 pm
Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-DRRC_20090914
SK edits.doc) uploaded
To: energyinterop@lists.oasis-open.org
> Hi Ed,
>
>
>
> You make valid points. In short, what we are saying
is this:
>
> 1. An agent (say
DRAS) will take the [potentially]
> computationallyintensive WS Calendar/Open ADR
structures/operations
> and sends simple load
> control/price messages depending on [some]
preferences as defined
> by one or
> more actors
>
> 2. Systems than
can natively process WS Calendar/Open ADR
> messages,can ignore messages in 1
>
>
>
> To me, #1 is functional requirements for a DRAS (or
whatever we
> call it).
> i.e. DRAS shall allow [a predefined set of] actors
to set
> preferences and
> constraints on message semantics based on certain
scheduling,
> price, and
> load control conditions. If DRAS will also
participate in all DER
> activity,and If this taskforce is tasked with
defining requirements
> for a DRAS, and
> if all agree that above is one of the requirements
then I have
> absolutely no
> problem whatsoever.
>
>
>
> On the other hand, if this taskforce is tasked with
defining
> interoperablemessage structures then I would have
problems with
> leaving the message
> semantics open to interpretation. The reason is
quite simple: although
> everything would work fine in the case of one to
many mapping
> between the
> utility and the consumer, in the case of many to
many (distributed
> M2M and
> DER) mapping between many actors, the interpreted
semantics will be
> ANYTHINGbut interoperable. One would then have to
find a mapping
> between a "Far" for
> me and a "Far" for you especially if there
is a device in the mix
> that can
> natively understand/process WS Calendar and Open ADR
messages.
>
>
>
> 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: Edward Koch [mailto:ed@akuacom.com]
> Sent: Thursday, December 03, 2009 10:28 PM
> To: energyinterop@lists.oasis-open.org
> Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-
> DRRC_20090914SK edits.doc) uploaded
>
>
>
> 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
> intelligentcontrollers in buildings that communicate
with a
> utility's headend in such a
> way that supports what Michel and Toby have
described and I would
> neversupport 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
> exchangeof 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
> nothingin 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
> simplifiedrepresentations 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:michel@universal-devices.com]
> Sent: Thursday, December 03, 2009 9:10 PM
> To: energyinterop@lists.oasis-open.org
> Subject: RE: [energyinterop] Groups - DR Programs
(DR-Program-
> DRRC_20090914SK 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/firmwaresolution 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:GGhatikar@lbl.gov]
> Sent: Thursday, December 03, 2009 7:23 PM
> To: michel@universal-devices.com
> Cc: energyinterop@lists.oasis-open.org
> Subject: Re: [energyinterop] Groups - DR Programs
(DR-Program-
> DRRC_20090914SK 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,
>
> No, you are not missing something. What I was trying
to say was:
> If simplicity is the result of all the research in
DR, then - in all
> likelihood - those results would be a little
antithetical to RTP
> simplybecause RTP is anything but simple (with
multiple actors and
> 10s of
> intertwined use cases).
>
> With kind regards,
>
> ********************************
> Michel Kohanim, C.E.O
> Universal Devices, Inc.
>
> (p) 818.631.0333
> (f) 818.436.0702
> http://www.universal-devices.com
> ********************************
>
>
>
Original Message-----
> From: Girish Ghatikar [mailto:GGhatikar@lbl.gov]
> Sent: Thursday, December 03, 2009 8:44 AM
> To: michel@universal-devices.com
> Cc: energyinterop@lists.oasis-open.org
> Subject: Re: [energyinterop] Groups - DR Programs
(DR-Program-
> DRRC_20090914SK edits.doc) uploaded
>
> Michel,
>
> It is my understanding that the scope issues to
addressed by EI TC
> for
> DR is beyond RTP. I am missing something?
>
> Some sentences from the original EI TC charter
purpose that might
> be
> relevant and to revisit:
>
> 1. "The Technical Committee will define the
interaction of Smart
> Grids
> with their end nodes: Smart Buildings and
Facilities, Enterprises,
> Industry, Homes, and Vehicles. Dynamic pricing,
reliability, and
> emergency signals must be communicated through
interoperability
> mechanisms that meet business needs, scale, use a
variety of
> communication technologies, maintain security and
privacy, and are
> reliable."
>
> 2. "These specifications will define service
interfaces and the
> data on
> which they operate to allow interoperation without
requiring deep
> knowledge of the systems as they are
implemented."
>
> Thanks,
> -Rish
>
> Michel Kohanim wrote:
>
>
> Hi Rish, welcome back!
>
> 1. I think we have to be a little careful with usage
of words such as
> "extensible and flexible" to define
"simple". In other words, we
> better
>
> come
>
>
> up with concrete requirements to "define"
what "simple" means. As
> of right
> now - and based on what I've read so far - to me
simple means "the
> usage
>
> of
>
>
> flags for devices that cannot compute anything above
and beyond
> base 3"
>
> 2. If in the future OpenADR is going to define the
communications
>
>
> standards
>
>
> for devices with an embedded ESI, then isn't WS
Scheduling part of the
>
>
> stack
>
>
> of operations they must be able to support? If so,
then where does
> thatleave "simple"?
>
> Please do not get me wrong for I truly believe in
simplicity. I
> would also
> be very interested in all the research and any
results thereof. My
> guess
>
> is
>
>
> that most of those results are a little antithetical
to real-time
> pricinggoals and aspirations.
>
>
> With kind regards,
>
>
> ********************************
> Michel Kohanim, C.E.O
> Universal Devices, Inc.
>
> (p) 818.631.0333
> (f) 818.436.0702
> http://www.universal-devices.com
> ********************************
>
>
>
Original Message-----
> From: Girish Ghatikar [mailto:GGhatikar@lbl.gov]
> Sent: Wednesday, December 02, 2009 8:13 PM
> To: michel@universal-devices.com
> Cc: energyinterop@lists.oasis-open.org
> Subject: Re: [energyinterop] Groups - DR Programs
>
>
> (DR-Program-DRRC_20090914
>
>
> SK edits.doc) uploaded
>
> Michel,
>
> Yes, it's been a long time - I was on travel for
last few weeks.
>
> 1. You're right that there will always be devices
with low
> processing
> power or capabilities to interpret the rich logic
and also from
> cost
> point of view this seem plausible. I am not saying
that that these
> devices do exist for certain in future, however, our
standards
> should be
> extensible and flexible enough to handle such
requirements. Again,
> this
> is not the only reason why the simple information
makes sense.
>
> 2. What you understand is correct and it's outside
of this scope
> (and
> always has been for OpenADR development) of the
communication
> between
> BAS/EMS/ESI/Meter/Gateway and end devices. However,
we can foresee
> that
> in future, that the OpenADR can directly communicate
with the
> devices
> (where ESI is integral part of the device itself.
>
> Another thing I didn't include in my earlier note
was an example of
> recently conducted PLP pilot where the existing CPP
DR program
> customers
> were switched without any reprogramming to their
controls or
> strategies
> although the original CPP was sending price
multipliers and the PLP
> sent
> the go to dispatch levels. The use of simple levels
from simple
> information made this possible.
>
> Thanks,
> -Rish
>
>
>
> Michel Kohanim wrote:
>
>
>
> Hi Rish, long time no see!
>
> 1. You are saying that: there are and shall be
devices/systems with
> low processing power and therefore we should support
simple messages.
>
>
> Yes?
>
>
> 2. Are HAN/Building communications within the
jurisdiction of this
> taskforce? i.e. are we going to discuss how
> BAS/EMS/ESI/Meter/Gateway/? communicate with end
devices? As far as
> I
> know, this is not the case unless the mandate has
changed. If no,
> then
> we have to decide what constitutes the minimum level
of "smartness"
> for a BAS/ESI/EMS
>
> 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:GGhatikar@lbl.gov]
> *Sent:* Wednesday, December 02, 2009 5:06 PM
> *To:* energyinterop@lists.oasis-open.org
> *Subject:* Re: [energyinterop] Groups - DR Programs
> (DR-Program-DRRC_20090914 SK edits.doc) uploaded
>
> David, Toby, and Michel:
>
> The purpose of using the terms simple and smart
client extends
> beyond
> the purposes of its use within legacy systems or
messages such as
> "FAR, NEAR, etc." This could be up to
local utility to define the
> precise interpretation for the customers. I think
this should be
> looked from the perspective of the DR information
(e.g.,
> reliability/emergency or price) that is sent to the
devices, which
> could come in many forms. This concept of simple vs.
smart
> information
> (client names are indicative of what information is
eventually used
> at
> end uses) is very important and the need has
originated from years
> of
> research, field tests, and commercial programs. For
me, it doesn't
> matter if it's called by some other name, the
information is the key.
>
> The idea here is not just to be supportive of legacy
or less
> sophisticated systems. It's also to make OpenADR
extensible and
> scalable to smaller devices and sectors such as
small commercial
> and
> residential, allow innovation and let systems
interoperate and
> offer
> scalable solutions such as the concept of
"bridge client" that we
> used
> within FM/RDS technology demonstration recently
(translating
> OpenADR
> smart information of hourly prices into simple
information of tiers
> and modes that PCTs could easily understand). In
particular, I
> would
> like to emphasize:
>
> *1. Legacy Systems:* While I partially agree to
Toby's comment,
> "Our
> work should be informed by legacy systems, but not
limited or
> dictated
> by them...," there is also a need to understand
to what end-use
> devices are we sending this information? The topic
of contention in
> most of the Smart Grid workshops has been -- how do we
address
> interoperability and standards with existing
installed base? I
> think
> it's obvious that we should not ignore it.
>
> *2. Less sophisticated clients: *We should make sure
that the
> existing
> or future devices have the ability to participate in
DR programs
> with
> lesser processing power (over logical translation of
smart
> information
> locally), which by themselves are not cost
prohibitive (more
> processing and logic = higher device costs). This is
also true of
> even
> sophisticated EMCS (with processing power) that
would like to make
> use
> of simple information to eliminate programming and
maintenance
> costs
> as they're tied to end-use strategies. This it's
apparent that the
> end-use strategies and those need simple mode
information (e.g.,
> NORMAL/MODERATE/HIGH). Of course any processing and
mapping of
> smart
> information could be derived by a middleware (e.g.,
DRAS in our
> case,
> which could be something else such as bridge client)
>
> *3. Extensibility and scalability to low processing
devices* -
> Understandably our current focus is on Commercial
and Industrial
> (CnI). However, in future we may also see the
results of the data
> models from this TC work getting extended to end-use
devises itself
> (e.g., lighting ballasts, appliances, etc.) and also
become part of
> other standards (e.g., SEP 2.0) and extend to other
sectors (e.g,
> residential and small commercial).
>
> *4. Allowing innovation and technology
interoperability and
> information standardization* - Simple information
allows us to
> cross
> boundaries and innovate that traditional
communication and/or
> technologies don't let us to. How will the end-use
devices
> interpret
> messages if we don't standardize these messages? An
example was
> bridge
> client that although used smart information (e.g.,
day-ahead hourly
> prices), the ability of standardization of simple
information
> allowed
> them to translate and transmit the same message in
simple form (the
> protocol translation from TCP/IP to FM/RDS messages
was a specific
> implementation for this bridge client) to PCTs due
to bandwidth and
> payload issues. In future, these same PCTs could
also directly
> listen
> to OpenADR simple information directly or through
third-party and
> interoperate with communication protocols and
technologies without
> any
> change in programming or strategies.
>
> This is a long way of saying that the concept of
simple and smart
> information is very important if we're designing the
smart grid for
> DR
> that is useful for not just the current systems,
however, also for
> likely future changes.
>
> If needed, I or someone here at LBNL can send more
information on
> field tests reports that cover the topics of smart
vs. simple clients.
>
> Thanks!
> -Rish
>
>
> Michel Kohanim wrote:
>
> Hi Ed,
>
> I would like to agree with you but having been
involved in many
> legacy
> integration projects makes me a little wary of
leaving
> constructs/vocabulary/nouns (or however you refer to
them) open for
> interpretation. You could obviously talk about user
preferences,
> criteria by which they are constrained, and where
they should be
> stored/exectuted (DRAS, Portal, EMS, end device,
etc.). This said,
> however - and in my view - system-to-system messages
should not be
> open to interpretation especially if they are
subjective like Far
> and
> Near.
>
> 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:* Edward Koch [mailto:ed@akuacom.com]
> *Sent:* Wednesday, December 02, 2009 11:51 AM
> *To:* Holmberg, David;
energyinterop@lists.oasis-open.org
> <mailto:energyinterop@lists.oasis-open.org>
> <mailto:energyinterop@lists.oasis-open.org>
> *Subject:* RE: [energyinterop] Groups - DR Programs
> (DR-Program-DRRC_20090914 SK edits.doc) uploaded
>
> David,
>
> What you are saying makes perfect sense, although I
would not
> classify
> the simple signal representations of OpenADR as DLC.
It really is
> nothing more than a more simplified representation
of the DR
> information that is sent in conjunction with (NOT
instead of) any
> other DR related information such as prices.
>
> The discussion started around the state variables in
the OpenADR
> message and then transformed into whether we should
support legacy
> systems. It's important that we not conflate those
two issues too
> much
> because while the vocabulary used to define the
simple state
> variables
> in the OpenADR message is driven by a desire to
support legacy
> systems
> the requirement to have an alternative vocabulary
whose semantics
> can
> be defined by the user for expressing DR event
information is
> actually
> a bigger question and is in fact anything but legacy
in its
> applicability and power. Having the option of an
alternative
> representation, especially if it can be defined and
controlled by
> the
> end user, does not dictate that it be used by the
end user. If they
> want to buy a new intelligent gateway in which to
embed all the
> intelligence there then so be it. I think that is a
fine way of
> automating DR, but it should not be the only one.
The key is in
> having
> options the end user can choose from that allow for
easier
> integration
> and consumption of DR signals in a fashion that
makes the most
> sense
> for the end user. The current mechanism in OpenADR
provides great
> flexibility in distributing intelligence and has
proven its worth
> in
> the currently deployed systems. Having alternative
representations
> of
> the DR information allows for the end user to decide
between those
> different representations AND allows for the
translation between
> those
> different representations to occur at different
points in the
> architecture. Could occur in the head end or it
could occur in the
> facility, or there may not be any translation at
all. I can tell
> you
> that current OpenADR implementations take advantage
of all three of
> those scenarios depending upon the needs of the end
user. The
> alternative is to restrict end user's options and
force them to
> consume information in a particular way which if the
decision is to
> explicitly NOT support legacy systems will result in
a standard
> that
> requires huge investments in new infrastructure
instead of the
> clean
> migration path via the options that OpenADR was
designed to provide.
>
> -ed koch
>
>
--------------------------------------------------------------------
> ----
>
> *From:* Holmberg, David
[mailto:david.holmberg@nist.gov]
> *Sent:* Wednesday, December 02, 2009 11:31 AM
> *To:* energyinterop@lists.oasis-open.org
> <mailto:energyinterop@lists.oasis-open.org>
> <mailto:energyinterop@lists.oasis-open.org>
> *Subject:* RE: [energyinterop] Groups - DR Programs
> (DR-Program-DRRC_20090914 SK edits.doc) uploaded
>
> OpenADR defines an architecture with a DRAS server
in the cloud.
> The
> DRAS server can send rich info to the smart DRAS
client, or more
> DLC-like info (I may be off base here, please
correct) to the
> simple
> clients. The simple client can't think so well, so
the server does
> more thinking and directing. It seems there is a
full spectrum of
> communications that span the collaborative pure
price approach to
> the
> "shut off the water heater" DLC approach.
>
> We are defining the information and messages for
energy
> interoperation
> at the facility interface (no?). We have said that
we would include
> the CA DR program messages that form the meat of
OpenADR--that is,
> "go
> to level 2, start time, duration". We are not
specifying how to
> talk
> to a specific device to make it act in a certain
way, as is the
> case
> for SEP--we are not defining messages for raising
the set-point
> temp,
> shutting off the water heater, etc. That is, such
commands are DLC,
> and the EMS handles that (even if, as in the case of
AMI, the EMS
> is
> in the utility backend system). So, EIX (Energy Info
eXchange
> protocol) will not compete with SEP for DLC,
although SEP has price
> communications. A utility can keep the current
"SEP from the back-
> end"
> approach, or stick an ESI on the building that
understands EIX
> messages and then translates that to SEP commands
(assuming that is
> in
> use on the HAN).
>
> Does this make sense?
>
> Thanks,
> David
>
>
Original Message-----
> From: Michel Kohanim
[mailto:michel@universal-devices.com]
> Sent: Wednesday, December 02, 2009 2:04 PM
> To: energyinterop@lists.oasis-open.org
> <mailto:energyinterop@lists.oasis-open.org>
> <mailto:energyinterop@lists.oasis-open.org>
> Subject: RE: [energyinterop] Groups - DR Programs
> (DR-Program-DRRC_20090914 SK edits.doc) uploaded
>
> Thanks Toby. I totally agree.
>
> With kind regards,
>
> ********************************
>
> Michel Kohanim, C.E.O
>
> Universal Devices, Inc.
>
> (p) 818.631.0333
>
> (f) 818.436.0702
>
> http://www.universal-devices.com
>
> ********************************
>
>
Original Message-----
>
> From: Considine, Toby (Campus Services IT)
> [mailto:Toby.Considine@unc.edu]
>
> Sent: Wednesday, December 02, 2009 10:59 AM
>
> To: 'energyinterop@lists.oasis-open.org
> <mailto:energyinterop@lists.oasis-open.org>
> <mailto:energyinterop@lists.oasis-open.org>'
>
> Subject: RE: [energyinterop] Groups - DR Programs
> (DR-Program-DRRC_20090914 SK edits.doc) uploaded
>
> I think the simple answer is no. Legacy systems work
with legacy
> communications. Some people will have a temporary
business of
> putting
> shims on old systems, whether they worked with
OpenADR, or with SEP
> 1.0, or even with a 3rd party such as ENERNOC.
>
> Our work should be informed by legacy systems, but
not limited or
> dictated by them...
>
> tc
>
> "A man should never be ashamed to own that he
has been in the
> wrong,
> which is but saying ... that he is wiser today than
yesterday." --
> Jonathan Swift
>
> Toby Considine
>
> Chair, OASIS oBIX TC
>
> Facilities Technology Office
>
> University of North Carolina
>
> Chapel Hill, NC
>
> Email: Toby.Considine@ unc.edu
>
> Phone: (919)962-9073
>
> http://www.oasis-open.org
>
> blog: www.NewDaedalus.com
<http://www.NewDaedalus.com>
> <http://www.NewDaedalus.com>
>
>
Original Message-----
>
> From: Michel Kohanim
[mailto:michel@universal-devices.com]
>
> Sent: Wednesday, December 02, 2009 1:36 PM
>
> To: energyinterop@lists.oasis-open.org
> <mailto:energyinterop@lists.oasis-open.org>
> <mailto:energyinterop@lists.oasis-open.org>
>
> Subject: RE: [energyinterop] Groups - DR Programs
> (DR-Program-DRRC_20090914 SK edits.doc) uploaded
>
> Hi Sila, thanks. That makes perfect sense.
>
> The next question is the scope of our efforts: do we
foresee
> supporting vintage systems?
>
> With kind regards,
>
> ********************************
>
> Michel Kohanim, C.E.O
>
> Universal Devices, Inc.
>
> (p) 818.631.0333
>
> (f) 818.436.0702
>
> http://www.universal-devices.com
>
> ********************************
>
>
--------------------------------------------------------------------
> -
>
> To unsubscribe from this mail list, you must leave
the OASIS TC that
>
> generates this mail. Follow this link to all your
TCs in OASIS at:
>
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> --
>
> Rish Ghatikar
> Lawrence Berkeley National Laboratory
> 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
> GGhatikar@lbl.gov
<mailto:GGhatikar@lbl.gov>
> <mailto:GGhatikar@lbl.gov> |
> +1 510.486.6768 | +1
> 510.486.4089 [fax]
>
>
> This email is intended for the addressee only and
may contain
> confidential information and should not be copied
without
> permission.
> If you are not the intended recipient, please
contact the sender as
> soon as possible and delete the email from
computer[s].
>
>
--------------------------------------------------------------------
> -
> To unsubscribe from this mail list, you must leave
the OASIS TC
> that
> generates this mail. Follow this link to all your
TCs in OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
> Rish Ghatikar
> Lawrence Berkeley National Laboratory
> 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
> GGhatikar@lbl.gov | +1 510.486.6768 | +1
510.486.4089 [fax]
>
>
>
> This email is intended for the addressee only and
may contain
> confidentialinformation and should not be copied
without
> permission. If you are not the
> intended recipient, please contact the sender as
soon as possible
> and delete
> the email from computer[s].
>
>
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
The information contained in this message is privileged and
intended only for the recipients named. If the reader is not a representative
of the intended recipient, any review, dissemination or copying of this message
or the information it contains is prohibited. If you have received this message
in error, please immediately notify the sender, and delete the original message
and attachments.