[Green] Re: Should GREEN cover batteries? (decision about negative instantaneous-power)

["[e-mail]" <[e-mail]>]

Hi Tony,

On 31/08/2026 17:05, Tony Li wrote:
> Hi Benoit,
>
>> Trying to close this issue, what are your views on
>>      1. we don't support battery (solar panel, etc) in our architecture: instantaneous-power is uint32
>>      2. the GREEN framework could support batteries in the future but we don't now: instantaneous-power is int32 and we explain the rational.
>>      3. the GREEN framework supports batteries now and we have a YANG module dedicated to batteries now: instantaneous-power is int32
>
> Every system that I have ever worked on has at least one (sometimes many) power supply(ies).  If you want to model components, then this deserves to be included now. Batteries are not a special case.
>
> Ergo, I propose:
>
> - Retain instantaneous-power as int32.  Add a comment saying that negative values are for power generating components.
That makes sense.
So the current spec is correct.

            leaf instantaneous-power {
              type int32;
              units "Watts";
              mandatory true;
              description
                "The power usage measurement for the energy object right now.
                This value represents the instantaneous power consumption
                of the component. This value is specified in SI units of watts
                with the magnitude of watts (milliwatts, kilowatts, etc.) indicated
                separately as unit-multiplier in this container. Positive values
                indicate power consumption, while negative values can indicate power
                generation (e.g., for devices with battery backup or
                renewable energy sources).";
            }

We could add some text about this, either in 
draft-ietf-green-power-and-energy-yang (I don't see it) or 
draft-ietf-green-framework-02 
<https://datatracker.ietf.org/doc/draft-ietf-green-framework/> (I 
haven't checked)
> - Nameplate-power becomes a int32. Same comment.
Thinking some more about it (and contradicting myself in my previous 
email), I am wondering whether it make sense?
Nameplate is a rating, not a flow. A 750 W supply is rated 750 W; what 
does a negative rating mean, since there is no instant at which a 
nameplate value is being measured in some direction. On top of that, for 
a battery, we need more attributes, such as energy capacity. What is 
confusing from the YANG leaf is "consume or produce", and this needs an 
update

           leaf nameplate-power {
              type uint32;
              units "Watts";
              description
                "The nameplate power rating of an energy object. This is
                the maximum power that the energy object is designed to consume or
                produce, as specified by the manufacturer. Essential for
                power budget calculations and capacity planning.";
            }

Proposal: keep uint32, but fix the description.

> - Total-energy-consumed becomes a int64. Same comment.
> - Delete total-energy-delivered.
I would keep the previous two together, as uint64. A sign is sufficient 
for a rate but insufficient for an accumulator. Instantaneous power is a 
value at an instant, so the sign carries the direction with no loss. A 
UPS battery that cycles daily has a net counter that oscillates around 
zero forever and conveys nothing: you lose the energy throughput, and 
you lose round-trip efficiency (delivered/consumed), which for a battery 
is the single most useful derived figure there is. On modelling a 
battery generally: the base model already carries one today with an 
iana-hardware identity called "battery", so source-component-id points 
at it; instantaneous-power signs the direction; the two energy counters 
accumulate charge and discharge; and the relationship list is keyed by 
type with an inner peer list, so an object can hold powered-by (its 
charger) and powering (the chassis it backs) at the same time. What a 
battery needs beyond that — state of charge, design vs actual capacity, 
cycle count, charge/discharge ratings, charging state — belongs in an 
augment. This last sentence is Option 3 in the initial list. I would not 
cover it in GREEN, personally.
Regards, Benoit
>
> Tony
>