Subject: Re: [eman] Power States != Charging States?

From: joel jaeggli <[email-masked]>
Date: Tue, 1 Oct 2013 08:40:41 -0700

On Sep 30, 2013, at 9:09 AM, Benoit Claise <[email-masked]> wrote:

> Hi Ted,
>> Hi Rolf
>> 
>> +1
>> 
>> Thanks for clearly articulating the points. I totally agree the charging state should be orthogonal to power state.
>> 
>> My position is that battery should _also_ have power state indicating if it is receiving power (charging) or giving power to the electrical network, and how much
> That makes sense.
> 
> Regards, Benoit

In my limited experience with battery controllers batteries are either:

charging
discharging
full
empty

in all cases  state of charge, e.g. capacity is germain.

>> 
>> This will be useful to account for all the power source and sink
>> 
>> Best
>> 
>> -tg-
>> Sent from my iPhone
>> 
>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter <[email-masked]> wrote:
>>> 
>>> Hi,
>>> 
>>> this thread attempts to close an open issue in the framework document (v10) where section 9.1.4 reads:
>>> 
>>> 9.1.4. Batteries Power State Set
>>> 
>>>        Batteries have operational and administrational states that
>>>        could be represented as a power state set. Since the work
>>>        for battery management is parallel to this document, we are
>>>        not proposing any Power State Sets for batteries at this
>>>        time.
>>> 
>>> I argue that batteries have no power states given the power state definition:
>>> 
>>>        A Power State is a condition or mode of a device that
>>>        broadly characterizes its capabilities, power
>>>        consumption, and responsiveness to input.
>>> 
>>> There are charging states currently defined in the battery MIB, which seem to be orthogonal to power states. I guess a universal power state set is "on" and "off". Any device can really be in one of these two modes. Even a simple light bulb. What would be "on" for a battery? Maybe charging because it receives energy (like any other device that is actually "on")? But every device that is on, fulfills its primary function. I would argue that the primary function of a battery is to provide energy. Batteries are different and I maybe we should ack this fact and not try to create battery power state sets just because we have this for devices.
>>> 
>>> I think the Email thread http://www.ietf.org/mail-archive/web/eman/current/msg02000.html seemed to agree that charging states and power states are orthogonal. If they are, why should they be of the same class? The problem is that the power state above as used for devices would suggest that if a device is off, it does not consume any energy. But if the battery is charging, then it does (given that the battery is modeled as part of the device). So if a power state is indeed conflating power consumption and capabilities, then a device would be in two different power states at the same time. But it is not. It is in one power state and the batteries in it are in a certain charging state and each of these can be freely combined. I.e. charging/on, discharging/on, charging/off etc... I guess the main question is, what is the advantage of defining a charging state as a power state (the set of charging states as a power state set)?
>>> 
>>> 
>>> Best,
>>> 
>>> Rolf
>>> 
>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014
>>> 
>>> 
>>> _______________________________________________
>>> eman mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman
>> .
>> 
> 
> 
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 1 Oct 2013 12:32:48 -0700

I agree with Rolf that the battery charging state is a different concept
from power state.

The current charging state entries in the battery MIB document are:
unknown, charging, fastCharging, maintainingCharge, noCharging, and
discharging.

It seems plausible to me that over time storage technologies will evolve so
that
more entries in this list will be desired.  The power state registry could
then be
used as a place to put such additional charging state sets, in which case
it should
be stated to cover both power and charging states.  Or, a second registry
just for
battery states could be created.  Or, states could be added by updating the
battery
MIB.

Note that a battery can have data only as listed in the battery MIB, it can
only
have component data as an energy object, or both.  For the energy object
aspect
of batteries, there is a field for the battery component for power state.
This could
be left empty, or used.  It occurs to me that a battery could be
available/in-use, which
I would consider to be On, or not electrically available (for charging or
discharging),
which I would consider to be Off (perhaps for being physically removed, or
simply
selected to be not available for use).  IEEE 1621 covers this.

Finally, I thought that the battery MIB draft had indications for battery
failure.  This
seems like something that could be reported on in either the charging state
or
power state context.

--Bruce

On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli <[email-masked]> wrote:

> >> Thanks for clearly articulating the points. I totally agree the
> charging state should be orthogonal to power state.
> >>
> >> My position is that battery should _also_ have power state indicating
> if it is receiving power (charging) or giving power to the electrical
> network, and how much
> > That makes sense.
> >
> > Regards, Benoit
>
> >>> There are charging states currently defined in the battery MIB, which
> seem to be orthogonal to power states. I guess a universal power state set
> is "on" and "off". Any device can really be in one of these two modes. Even
> a simple light bulb. What would be "on" for a battery? Maybe charging
> because it receives energy (like any other device that is actually "on")?
> But every device that is on, fulfills its primary function. I would argue
> that the primary function of a battery is to provide energy. Batteries are
> different and I maybe we should ack this fact and not try to create battery
> power state sets just because we have this for devices.
> >>>
> >>> I think the Email thread
> http://www.ietf.org/mail-archive/web/eman/current/msg02000.html seemed to
> agree that charging states and power states are orthogonal. If they are,
> why should they be of the same class? The problem is that the power state
> above as used for devices would suggest that if a device is off, it does
> not consume any energy. But if the battery is charging, then it does (given
> that the battery is modeled as part of the device). So if a power state is
> indeed conflating power consumption and capabilities, then a device would
> be in two different power states at the same time. But it is not. It is in
> one power state and the batteries in it are in a certain charging state and
> each of these can be freely combined. I.e. charging/on, discharging/on,
> charging/off etc... I guess the main question is, what is the advantage of
> defining a charging state as a power state (the set of charging states as a
> power state set)?
> >>>
> >>>
> >>> Best,
> >>>
> >>> Rolf
> >>>
> >>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> West End  Road, London, HA4 6QE, GB | Registered in England 2832014
> >>>
> >>>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov*
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Rolf Winter <[email-masked]>
Date: Wed, 2 Oct 2013 10:01:50 +0000

Hi,

So it seems there is a general agreement that power and charging states are different. But I am still not sure we need a separate power state. I think I read two different things so far.

1) introduce a state that shows if it is charging or discharging and how much 
2) introduce state which merely indicates whether the battery can be used (either charged or discharged or not)

I thought 1 is already covered by the current battery MIB with charging states and the actual measurements of e.g. the actual current etc. The same I guess applied to devices which might have a couple of power states and then actual measurements to quantify energy use.

I am not sure about 2 since I have a hard time making a connection with the definition of power state that we have:

It is more like "availability for use" rather than an actual power state. That however is currently not covered by the MIB and we can think about whether we should introduce this.

Best,

Rolf

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bruce Nordman
> Sent: Dienstag, 1. Oktober 2013 21:33
> To: joel jaeggli
> Cc: Ted Ghose; [email-masked]
> Subject: Re: [eman] Power States != Charging States?
> 
> I agree with Rolf that the battery charging state is a different
> concept from power state.
> 
> 
> It seems plausible to me that over time storage technologies will
> evolve so that
> 
> more entries in this list will be desired.  The power state registry
> could then be used as a place to put such additional charging state
> sets, in which case it should be stated to cover both power and
> charging states.  Or, a second registry just for
> 
> battery states could be created.  Or, states could be added by updating
> the battery MIB.
> 
> 
> Note that a battery can have data only as listed in the battery MIB, it
> can only have component data as an energy object, or both.  For the
> energy object aspect of batteries, there is a field for the battery
> component for power state.  This could be left empty, or used.  It
> occurs to me that a battery could be available/in-use, which I would
> consider to be On, or not electrically available (for charging or
> discharging), which I would consider to be Off (perhaps for being
> physically removed, or simply selected to be not available for use).
> IEEE 1621 covers this.
> 
> 
> Finally, I thought that the battery MIB draft had indications for
> battery failure.  This seems like something that could be reported on
> in either the charging state or
> 
> power state context.
> 
> --Bruce
> 
> 
> 
> 	>> Thanks for clearly articulating the points. I totally agree
> the charging state should be orthogonal to power state.
> 	>>
> 	>> My position is that battery should _also_ have power state
> indicating if it is receiving power (charging) or giving power to the
> electrical network, and how much
> 	> That makes sense.
> 	>
> 	> Regards, Benoit
> 
> 
> 	>>> this thread attempts to close an open issue in the framework
> document (v10) where section 9.1.4 reads:
> 	>>>
> 	>>> There are charging states currently defined in the battery
> MIB, which seem to be orthogonal to power states. I guess a universal
> power state set is "on" and "off". Any device can really be in one of
> these two modes. Even a simple light bulb. What would be "on" for a
> battery? Maybe charging because it receives energy (like any other
> device that is actually "on")? But every device that is on, fulfills
> its primary function. I would argue that the primary function of a
> battery is to provide energy. Batteries are different and I maybe we
> should ack this fact and not try to create battery power state sets
> just because we have this for devices.
> 	>>>
> 	>>> I think the Email thread http://www.ietf.org/mail-
> archive/web/eman/current/msg02000.html seemed to agree that charging
> states and power states are orthogonal. If they are, why should they be
> of the same class? The problem is that the power state above as used
> for devices would suggest that if a device is off, it does not consume
> any energy. But if the battery is charging, then it does (given that
> the battery is modeled as part of the device). So if a power state is
> indeed conflating power consumption and capabilities, then a device
> would be in two different power states at the same time. But it is not.
> It is in one power state and the batteries in it are in a certain
> charging state and each of these can be freely combined. I.e.
> charging/on, discharging/on, charging/off etc... I guess the main
> question is, what is the advantage of defining a charging state as a
> power state (the set of charging states as a power state set)?
> 	>>>
> 	>>>
> 	>>> Best,
> 	>>>
> 	>>> Rolf
> 	>>>
> 	>>> NEC Europe Ltd | Registered Office: Athene, Odyssey Business
> Park, West End  Road, London, HA4 6QE, GB | Registered in England
> 2832014
> 	>>>
> 	>>>
> Bruce Nordman
> nordman.lbl.gov

---

From: Ted Ghose <[email-masked]>
Date: Wed, 2 Oct 2013 13:53:39 +0000

We still need to know know the amount of power battery is receiving or giving to the system. 

How are we addressing that? 

I totally agree charging state has nothing to do with it 

-tg-
Sent from my iPhone

> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" <[email-masked]> wrote:
> 
> Hi,
>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 2 Oct 2013 14:23:01 +0000

So I'm seeing we all agree charing states are orthogonal to the current power states.
That it's reasonable to expect a battery modeled by an Energy Object to implement power states to show what it is receiving or giving to the system.

+1 On Bruce's comment in it;s entirety also that we could include the battery states in power states at some later date.

Rolf I'm not sure I see that the definition of power states does not cover states of a battery. "A condition or mode that broadly characterize..power..." does seem to cover if a battery is receving energy and storing it? Anyone else see this is ok or not?

I did bring up that we call these power states when "energy states" and "energy interfaces" is more accurate. Would that be more comfortable to you. ETSI is using Energy States in their liaison with us is the GAL.

I will update 9.1.4 according to this thread an lets see how that rolls.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes)

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 2 Oct 2013 11:22:06 -0700

For reporting power/energy, a battery would typically be modeled as a
component
and so report power/energy values as any other component would (this a
subset
of a device would report since components do not report complex power).
That is, a battery has battery MIB data, as well as component (energy
object) data.
We would expect devices to report both, though they could do just one or
the other.
--Bruce

On Wed, Oct 2, 2013 at 6:53 AM, Ted Ghose <[email-masked]> wrote:

> > So it seems there is a general agreement that power and charging states
> are different. But I am still not sure we need a separate power state. I
> think I read two different things so far.
> >
> > 2) introduce state which merely indicates whether the battery can be
> used (either charged or discharged or not)
> >
> > I thought 1 is already covered by the current battery MIB with charging
> states and the actual measurements of e.g. the actual current etc. The same
> I guess applied to devices which might have a couple of power states and
> then actual measurements to quantify energy use.
> >
> > I am not sure about 2 since I have a hard time making a connection with
> the definition of power state that we have:
> >
> > It is more like "availability for use" rather than an actual power
> state. That however is currently not covered by the MIB and we can think
> about whether we should introduce this.
> >
> > Best,
> >
> > Rolf
> >
> >
> >
> > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West
> End  Road, London, HA4 6QE, GB | Registered in England 2832014
> >
> >

---

From: Rolf Winter <[email-masked]>
Date: Tue, 8 Oct 2013 08:44:25 +0000

Hi,

I agree, but I think this should be done through actual measurements not through states.

Best,

Rolf 

> From: Ted Ghose [mailto:[email-masked]]
> Sent: Mittwoch, 2. Oktober 2013 15:54
> To: Rolf Winter
> Cc: Bruce Nordman; EXT - [email-masked]; [email-masked]
> > So it seems there is a general agreement that power and charging
> states are different. But I am still not sure we need a separate power
> state. I think I read two different things so far.
> >
> > I thought 1 is already covered by the current battery MIB with
> charging states and the actual measurements of e.g. the actual current
> etc. The same I guess applied to devices which might have a couple of
> power states and then actual measurements to quantify energy use.
> >
> > I am not sure about 2 since I have a hard time making a connection
> with the definition of power state that we have:
> >
> > A Power State is a condition or mode of a device that broadly
> > characterizes its capabilities, power consumption, and responsiveness
> > to input.
> >
> state. That however is currently not covered by the MIB and we can
> think about whether we should introduce this.
> >
> > Best,
> >
> > Rolf
> >
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Bruce Nordman
> >> battery states could be created.  Or, states could be added by
> >> updating the battery MIB.
> >>
> >>
> >> Note that a battery can have data only as listed in the battery MIB,
> >> it can only have component data as an energy object, or both.  For
> >> the energy object aspect of batteries, there is a field for the
> >> battery component for power state.  This could be left empty, or
> >> used.  It occurs to me that a battery could be available/in-use,
> >> which I would consider to be On, or not electrically available (for
> >> charging or discharging), which I would consider to be Off (perhaps
> >> for being physically removed, or simply selected to be not available
> for use).
> >> IEEE 1621 covers this.
> >>
> >>
> the
> >> states and power states are orthogonal. If they are, why should they
> >> be of the same class? The problem is that the power state above as
> >> used for devices would suggest that if a device is off, it does not
> >> consume any energy. But if the battery is charging, then it does
> >> (given that the battery is modeled as part of the device). So if a
> >> power state is indeed conflating power consumption and capabilities,
> >> then a device would be in two different power states at the same
> time. But it is not.
> >> Lawrence Berkeley National Laboratory nordman.lbl.gov
> >> [email-masked]
> >> 510-486-7089
> >> m: 510-501-7943
> >
> >
> >

---

From: Rolf Winter <[email-masked]>
Date: Tue, 8 Oct 2013 16:29:04 +0000

Hi John,

when you snip text out of a definition I think you can make anything fit that defintion. But you snipped important things like the "consumption" bit after "power" or "responsiveness to input". 

Best,

Rolf

> From: John Parello (jparello) [mailto:[email-masked]]
> Sent: Mittwoch, 2. Oktober 2013 16:23
> To: Ted Ghose
> Cc: Rolf Winter; [email-masked]
> That it's reasonable to expect a battery modeled by an Energy Object to
> implement power states to show what it is receiving or giving to the
> system.
> 
> +1 On Bruce's comment in it;s entirety also that we could include the
> battery states in power states at some later date.
> 
> Rolf I'm not sure I see that the definition of power states does not
> cover states of a battery. "A condition or mode that broadly
> characterize..power..." does seem to cover if a battery is receving
> energy and storing it? Anyone else see this is ok or not?
> 
> I did bring up that we call these power states when "energy states" and
> "energy interfaces" is more accurate. Would that be more comfortable to
> you. ETSI is using Energy States in their liaison with us is the GAL.
> 
> >>> for being physically removed, or simply selected to be not
> available for use).
> >>> IEEE 1621 covers this.
> >>>
> >>>
> >>> battery failure.  This seems like something that could be reported
> >>> on in either the charging state or
> >>>
> >>> power state context.
> >>>
> >>> --Bruce
> >>>
> >>>
> >>>
> >>> indicating if it is receiving power (charging) or giving power to
> >>> the electrical network, and how much
> >>>> That makes sense.
> >>>>
> >>>> Regards, Benoit
> >>>
> >>>
> >>> MIB, which seem to be orthogonal to power states. I guess a
> >>> universal power state set is "on" and "off". Any device can really
> >>> be in one of these two modes. Even a simple light bulb. What would
> >>> be "on" for a battery? Maybe charging because it receives energy
> >>> (like any other device that is actually "on")? But every device
> that
> >>> is on, fulfills its primary function. I would argue that the
> primary
> >>> function of a battery is to provide energy. Batteries are different
> >>> and I maybe we should ack this fact and not try to create battery

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 8 Oct 2013 17:07:05 +0000

Very true. Whether these are power state or more encompassing I like the idea of the registry we came up with and then the devices listing which ones they implement.

We've accepted that they do not need to overlap so for me I'd rather broaden the scope of the series and states  like.

(again I prefer energy state but...)
"""
A Power State is a condition or mode of a device that broadly
characterizes its capabilities, power, and function
"""

That would cover charging states?

So a device could implement:

Series:

[0] IEEE:  on, off, sleep
[1] BATTERY: unknown, charging, fastCharging, maintainingCharge, noCharging, discharging

If could also be modeled as a device with a battery component each with one series.

Jp

________________________________________
From: Rolf Winter [[email-masked]]
Sent: Tuesday, October 08, 2013 9:29 AM
To: John Parello (jparello); Ted Ghose
Cc: [email-masked]
Subject: RE: [eman] Power States != Charging States?

Hi John,

Best,

Rolf

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 10 Oct 2013 09:37:51 +0000

Hi,

I would agree with Joel Jaggli's suggestion on battery states -

http://www.ietf.org/mail-archive/web/eman/current/msg02010.html

charging
discharging
full
Empty

Thanks
Mouli

Series:

[0] IEEE:  on, off, sleep

Jp

________________________________________
From: Rolf Winter [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 08, 2013 9:29 AM
To: John Parello (jparello); Ted Ghose
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [eman] Power States != Charging States?

Hi John,

Best,

Rolf

-----Original Message-----
From: John Parello (jparello) [mailto:[email-masked]]
Sent: Mittwoch, 2. Oktober 2013 16:23
To: Ted Ghose
Cc: Rolf Winter; [email-masked]<mailto:[email-masked]>
Subject: Re: [eman] Power States != Charging States?

So I'm seeing we all agree charing states are orthogonal to the current
power states.
That it's reasonable to expect a battery modeled by an Energy Object to
implement power states to show what it is receiving or giving to the
system.

Jp

Sent from my iPad

On Oct 2, 2013, at 6:56 AM, "Ted Ghose" <[email-masked]<mailto:[email-masked]>> wrote:

>> On Oct 2, 2013, at 3:04 AM, "Rolf Winter" <[email-masked]<mailto:[email-masked]>>
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf
>>> Cc: Ted Ghose; [email-masked]<mailto:[email-masked]>
available for use).
>>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli <[email-masked]<mailto:[email-masked]>>
wrote:
>>>
>>>
>>>
>>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>
>>>> Hi Ted,
>>>>> Hi Rolf
>>>>>
>>>>> +1
>>>>>
>>>>>> On Sep 25, 2013, at 6:18 AM, Rolf Winter
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
that
primary
time. But it is not.
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>>   [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>>> 510-486-7089
>>> m: 510-501-7943
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

---

From: Rolf Winter <[email-masked]>
Date: Fri, 11 Oct 2013 07:57:48 +0000

Hi,

I would like to disagree. There is an actual reason why we have the following in the current battery MIB:

unknown(1),
charging(2),
fastCharging(3),
maintainingCharge(4),
noCharging(5),
discharging(6),
notSet(7)

These are existing charging states. Full and empty are not charging states they describe the actual charge (we have that in the MIB)! If new sets that alter the current MIB set are proposed, then I would expect an actual justification. BTW, I didn't read Joel's Email as an proposal to actually change the MIB definitions.

Best,

Rolf

> Mouli Chandramouli (moulchan)
> Sent: Donnerstag, 10. Oktober 2013 11:38
> To: [email-masked]
> Subject: [eman] Power States != Charging States?
> 
> Hi,
> 
> Very true. Whether these are power state or more encompassing I like
> the idea of the registry we came up with and then the devices listing
> which ones they implement.
> 
> We've accepted that they do not need to overlap so for me I'd rather
> broaden the scope of the series and states  like.
> 
> characterizes its capabilities, power, and function """
> 
> when you snip text out of a definition I think you can make anything
> fit that defintion. But you snipped important things like the
> "consumption" bit after "power" or "responsiveness to input".
> 
> Best,
> 
> Rolf
> 
> 	> We still need to know know the amount of power battery is
> receiving
> 	or giving to the system.
> 	>
> 	>> On Oct 2, 2013, at 3:04 AM, "Rolf Winter"
> <[email-masked]>
> 	wrote:
> 	>>
> 	>> Hi,
> 	>>
> 	>> 1) introduce a state that shows if it is charging or
> discharging and
> 	>> how much
> Park,
> 	>>> On Tue, Oct 1, 2013 at 8:40 AM, joel jaeggli
> <[email-masked]>
> 	wrote:
> 	>>>
> 	>>>
> 	>>>
> 	>>>   On Sep 30, 2013, at 9:09 AM, Benoit Claise
> <[email-masked]>
> 	>>> wrote:
> 	>>>
> 	>>>> Hi Ted,
> 	>>>>> Hi Rolf
> 	>>>>>
> 	>>>>> +1
> 	>>>>>
> 	>>>   In my limited experience with battery controllers batteries
> are
> 	>>> either:
> 	>>>
> 	>>>   charging
> 	>>>   discharging
> 	>>>   full
> 	>>>   empty
> 	>>>
> 	>>> <[email-masked]> wrote:
> 	>>>>>>
> 	>>>>>> Hi,
> 	>>>>>>
> 	>>>>>>       Batteries have operational and administrational
> states
> 	>>> that
> 	>>>>>> I argue that batteries have no power states given the
> power
> 	>>> state definition:
> 	>>>>>>
> 	>>> states and power states are orthogonal. If they are, why
> should
> 	they
> 	>>> question is, what is the advantage of defining a charging
> state as
> 	a

---

From: joel jaeggli <[email-masked]>
Date: Fri, 11 Oct 2013 01:31:30 -0700

> These are existing charging states. Full and empty are not charging states they describe the actual charge (we have that in the MIB)! If new sets that alter the current MIB set are proposed, then I…

it wasn't

---

From: Rolf Winter <[email-masked]>
Date: Fri, 11 Oct 2013 14:58:53 +0000

I think we should step back before watering down a definition that made a lot of sense to me. The question is what we want to achieve. I heard some people wanted power states _plus_ charging states for a battery. If that is what we want then what you propose doesn't make a whole lot of sense since a battery can be in two different power states that express very different things. If we want to use a common registry, I am fine with that but I don't see why we need to alter standard terms for that. If the two are mutually exclusive then you won't have a problem. I actually prefer to have a registry for charging (or power or the two combined in a single registry) states since we will potentially see a number of additional charging states in the future as battery technology evolves.

Best, 

Rolf

> Sent: Dienstag, 8. Oktober 2013 19:07
> To: Rolf Winter
> Cc: [email-masked]
> > That it's reasonable to expect a battery modeled by an Energy Object
> > to implement power states to show what it is receiving or giving to
> > the system.
> >
> > I did bring up that we call these power states when "energy states"
> > and "energy interfaces" is more accurate. Would that be more
> > comfortable to you. ETSI is using Energy States in their liaison with
> us is the GAL.
> >
> > >> 2) introduce state which merely indicates whether the battery can
> > >> be used (either charged or discharged or not)
> > >>
> > >>> unknown, charging, fastCharging, maintainingCharge, noCharging,
> > >>> and discharging.
> > >>>
> > >>> could then be used as a place to put such additional charging
> > >>> state sets, in which case it should be stated to cover both power
> > >>> and charging states.  Or, a second registry just for
> > >>>
> > >>> Note that a battery can have data only as listed in the battery
> > >>> MIB, it can only have component data as an energy object, or both.
> > >>> For the energy object aspect of batteries, there is a field for
> > >>> the battery component for power state.  This could be left empty,
> > >>> or used.  It occurs to me that a battery could be
> > >>> available/in-use, which I would consider to be On, or not
> > >>> electrically available (for charging or discharging), which I
> > >>> would consider to be Off (perhaps for being physically removed,
> or
> > >>> simply selected to be not
> > available for use).
> > >>> IEEE 1621 covers this.
> > >>>
> > >>>
> > >>> function of a battery is to provide energy. Batteries are
> > >>> different and I maybe we should ack this fact and not try to
> > >>> create battery power state sets just because we have this for
> devices.
> > >>>>>>
> > >>> used for devices would suggest that if a device is off, it does
> > >>> not consume any energy. But if the battery is charging, then it
> > >>> does (given that the battery is modeled as part of the device).
> So
> > >>> if a power state is indeed conflating power consumption and
> > >>> capabilities, then a device would be in two different power
> states
> > >>> at the same
> > time. But it is not.
> > >>> question is, what is the advantage of defining a charging state
> as
> > a