[Nut-upsdev] NUT namespace: RFC for new variable addition

[Charles Lepple]

On May 24, 2017, at 7:56 AM, Jim Klimov <jimklimov at cos.ru> wrote:
> 
> On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple <clepple at gmail.com> wrote:
>> I don't think "dephasing" is common usage, but "phase shift" should
>> suffice.
>> 
>> Also, how does this apply to 3-phase systems? Is it nominally 120
>> degrees?
>> 
>> Strange that this has not come up before.
> 
> It was my impression too. However it seems the 'phase shift' usually refers to lag between Amperage and Voltage waves, while this issue is (if I get it correctly) about two separate ATS inputs fluctuating on their own different clock-offsets. Should be same freq (50 or 60) though, or likely assumed so - which might not be guaranteed in real life either ;) On the other hand, if the freqs differ, this reported skew degree will vary over time (if detected and reported honestly)...

Then maybe I am not understanding what the original variable name ("input.phase.shift") is referring to. We can always go back and update the documentation to clarify, but variable names really shouldn't change once merged. I think this is a little too close to "input.phases".

It does seem from the MIB that this refers to two different inputs, rather than multiple phases of the same input (my mistake).

Most of the Google search results I see for "dephasing" are related to quantum systems or medical imaging, aside from the Eaton MIB itself.

NUT is basically middleware for power devices. If we just publish everything that the device reports without understanding what we are reporting, there is little added value. In particular, if another device has a similar value to report, I think we need a description that is good enough to match another vendor's description of the same value.