Subject: Re: [eman] [EMAN-BATTERY]: power state set

From: Benoit Claise <[email-masked]>
Date: Tue, 02 Aug 2011 18:20:00 +0200

So, as discussed during the meeting, on based on this dicussion on the 
list,  the battery should be integrated to the framework, with its own 
UUID, with its own power state set/power state, and on the top of this, 
it should support the battery-mib. Correct?

Regards, Benoit.
> +1  I believe that the two sets of states are orthogonal.
>
> When people talk about a device charging they are simply being imprecise and conflating the two.  It is an artifact of informal speech.
>
> William F. Mielke
> Alcatel-Lucent
> Distinguished Member of Technical Staff
> 6200 East Broad Street
> Room: 4B01-1V
> Columbus, OH  43213-1530
> Email: [email-masked]
> Phone: 614 367 5628
> Fax: 614 367 5965
>
> "Live like you're going to die tomorrow.
>   Learn like you're going to live forever."
>
>      - Albert Einstein
>
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Rolf Winter
>> Sent: Thursday, July 28, 2011 12:50 PM
>> To: John Parello (jparello); Bruce Nordman; Benoit Claise (bclaise)
>> Cc: eman mailing list
>> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>>
>> I think these states are completely independent. Take the
>> three power states on, sleep, off and the charging states
>> charging, discharging, maintaining charge. Which ones are
>> dependent on each other? I think any of these combinations
>> work. Answering Benoit's question, I believe these are orthogonal.
>>
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
>> Road, London W3 6BL | Registered in England 2832014
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of
>>> John Parello (jparello)
>>> Sent: Donnerstag, 28. Juli 2011 18:29
>>> To: Bruce Nordman; Benoit Claise (bclaise)
>>> Cc: eman mailing list
>>> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>>>
>>>
>>> OK but thinking about it. I'm not sure the battery state is
>> independent
>>> of the device in all cases.
>>>
>>> Tablet example. We refer to them as on, off, charging, etc. We don't
>>> say the device is on and the battery is off. It's merged.
>>>
>>> So while I agree they can be separate we have to allow for the case
>>> when they are combined as well.
>>>
>>> Jp
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] on behalf of Bruce Nordman
>>> Sent: Thu 7/28/2011 9:12 AM
>>> To: Benoit Claise (bclaise)
>>> Cc: eman mailing list
>>> Subject: Re: [eman] [EMAN-BATTERY]: power state set
>>>
>>> On Thu, Jul 28, 2011 at 11:34 AM, Benoit Claise<[email-masked]>
>>> wrote:
>>>
>>>> Rolf,
>>>>
>>>>   +1
>>>>> The problem is that the power states of a "regular"
>> device conflate
>>>>> operational state information and energy related state
>> information.
>>>>> The battery charging state does not I in the same way.
>>>>>
>>>> This is actually my question.
>>>> Is the battery power state set orthogonal to the other 3
>> power state
>>> sets?
>>> A power state is (in principle) something independent of
>> the device (or
>>> component) type.
>>> It is universal.
>>>
>>> The battery state is specific to a single type of component
>>>
>>> I can imagine setting a power state for a battery to "off": to
>>> electrically disconnect it to prevent charging or discharging (this
>>> might be done prior to removal for example).  In this case,
>> a battery
>>> would want both a power state and a charging state (the power state
>>> variable would be in the other MIB so not added to the Battery MIB).
>>>
>>> If new battery states might be needed, how about simply having a
>>> registry of the current states so that individual states
>> could be added,
>>> rather than entire new series as we have with power states.
>>   This would
>>> give flexibility to add in future with minimal complexity, and not
>>> conflate with power states.
>>>
>>> --Bruce
>>>
>>>> Regards, Benoit.
>>>>
>>>> ...
>>>>
>>> --
>>> *Bruce Nordman*
>>> Lawrence Berkeley National Laboratory
>>> eetd.lbl.gov/ea/nordman
>>> [email-masked]
>>> 510-486-7089
>>> m: 510-501-7943
>>>
>>>
>> _______________________________________________
>> 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: Juergen Quittek <[email-masked]>
Date: Wed, 3 Aug 2011 11:04:43 +0200

Dear all,

The framework should be open to support two ways of representing a battery:

1. treating the battery as a part of a device (or entity).
2. treating a battery as a separate entity with its own MIB objects for power and energy.

In case 1, there is no separate Power MIB instance for the battery. 
Power reports on the containing device will include the power 
received or provided by the internal battery.

In case 2, the battery will have it's own Power MIB objects, 
either hosted by a battery module or a parent of it.

In case 1 the battery MAY have a UUID, in case 2 the battery MUST have a UUID.

In both cases the Battery MIB may be used for providing information on the battery.

In case 2 it is not clear what a power state of a battery is. I see two alternatives (a) and (b):

(a) it can be limited to just "on" and "off". 
How much the battery is charged and the actual charging or discharging activities 
would then not be considered as power state, but rather as the battery's operational state.

(b) it can the union of "on" and the set of charging states defined in the battery MIB
In  this case we would have to register a battery state set at IANA, 
because the power state sets of DMTF, ACPI, and EnergyWise would not be applicable.  

If we have consensus that power states and charging states are orthogonal, 
then our choice should be (a).

Thanks,

    Juergen

We would have to define what a power state 
Am 02.08.2011 um 18:20 schrieb Benoit Claise:

> So, as discussed during the meeting, on based on this dicussion on the list,  the battery should be integrated to the framework, with its own UUID, with its own power state set/power state, and on the top of this, it should support the battery-mib. Correct?
> 
> Regards, Benoit.