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

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" <Rolf.Winter@neclab.eu> wrote:
> 
> 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:
> 
> A Power State is a condition or mode of a device that
> broadly characterizes its capabilities, power
> consumption, and responsiveness to input. 
> 
> 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
> 
> 
>> -----Original Message-----
>> From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>> Bruce Nordman
>> Sent: Dienstag, 1. Oktober 2013 21:33
>> To: joel jaeggli
>> Cc: Ted Ghose; eman@ietf.org
>> Subject: Re: [eman] Power States != Charging States?
>> 
>> 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 <joelja@bogus.com> wrote:
>> 
>> 
>> 
>>    On Sep 30, 2013, at 9:09 AM, Benoit Claise <bclaise@cisco.com>
>> 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
>> <Rolf.Winter@neclab.eu> 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
>>    >>> eman@ietf.org
>>    >>> https://www.ietf.org/mailman/listinfo/eman
>>    >> _______________________________________________
>>    >> eman mailing list
>>    >> eman@ietf.org
>>    >> https://www.ietf.org/mailman/listinfo/eman
>>    >> .
>>    >>
>>    >
>>    >
>>    > _______________________________________________
>>    > eman mailing list
>>    > eman@ietf.org
>>    > https://www.ietf.org/mailman/listinfo/eman
>>    >
>> 
>> 
>> 
>>    _______________________________________________
>>    eman mailing list
>>    eman@ietf.org
>>    https://www.ietf.org/mailman/listinfo/eman
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Bruce Nordman
>> Lawrence Berkeley National Laboratory
>> nordman.lbl.gov
>> BNordman@LBL.gov
>> 510-486-7089
>> m: 510-501-7943
> 
> 
> 