Nut upsdev - Jan 2007 - Differences between newhidups (MGE tables) in 2.0.4 and svn trunk

I was looking at how other drivers deal with outlet collections, and I
noticed some differences between newhidups in 2.0.4 (from Debian's
2.0.4-2.3) and the SVN trunk (rev 723) on an Evolution. Full diff is
below, but here are the highlights:

 * MGE HID 0.9 vs 1.0
 * outlet.#.switch seems to have moved to the commands outlet.#.load.{on,off}

Then I found this in the ChangeLog:

   * fix outlet.X.delay.{shutdown,start} and add temporary
     commands (to be discussed) outlet.X.load.{on,off}. This
     last would better be addressed through parameters of the
     load.{on,off} command.

For the on/off commands, couldn't we just use the upsrw-style
variables and the existing names? It seems that optiups and mge-shut.h
still use the outlet.#.switch variables.

Also, the older drivers seem to use 0/1 for the on/off values. We
should probably stick with 0/1 for simplicity, or implement a "boolean
parser" that maps "1", "on", "true", etc to
1, and others to 0.

Thoughts?

$ diff -u /tmp/newhidups /tmp/usbhid-ups
--- /tmp/newhidups      2007-01-08 21:25:54.000000000 -0500
+++ /tmp/usbhid-ups     2007-01-08 21:26:41.000000000 -0500
@@ -1,13 +1,15 @@
 battery.charge: 100
 battery.charge.low: 30
+battery.charge.restart: 0
 battery.runtime: 3150
+battery.type: PbAc
 battery.voltage: 121.0
 driver.name: newhidups
 driver.parameter.pollinterval: 15
 driver.parameter.port: auto
-driver.version: 2.0.4
-driver.version.data: MGE HID 0.9
-driver.version.internal: 0.28
+driver.version: 2.1.0
+driver.version.data: MGE HID 1.0
+driver.version.internal: 0.30
 input.frequency: 60.0
 input.transfer.boost.low: 102.0
 input.transfer.high: 151.0
@@ -16,26 +18,26 @@
 input.voltage: 121.0
 outlet.0.desc: Main Outlet
 outlet.0.id: 0
-outlet.0.switchable: 0
+outlet.0.switchable: no
 outlet.1.autoswitch.charge.low: 0
 outlet.1.delay.shutdown: 65535
-outlet.1.delay.start: 65535
+outlet.1.delay.start: 3
 outlet.1.desc: PowerShare Outlet 1
 outlet.1.id: 1
-outlet.1.switch: 1
-outlet.1.switchable: 1
+outlet.1.status: on
+outlet.1.switchable: yes
 outlet.2.autoswitch.charge.low: 0
 outlet.2.delay.shutdown: 65535
-outlet.2.delay.start: 65535
+outlet.2.delay.start: 6
 outlet.2.desc: PowerShare Outlet 2
 outlet.2.id: 2
-outlet.2.switch: 1
-outlet.2.switchable: 1
+outlet.2.status: on
+outlet.2.switchable: yes
 output.current: inf
-output.frequency: 0.0
+output.frequency: 60.0
 output.voltage: 121.0
-output.voltage.target.battery: 120.0
-output.voltage.target.line: 120.0
+output.voltage.nominal: 120.0
+ups.beeper.status: enabled
 ups.delay.shutdown: 65535
 ups.delay.start: 655350
 ups.load: 8


-- 
- Charles Lepple

2007/1/9, Charles Lepple <clepple@gmail.com>:
> I was looking at how other drivers deal with outlet collections, and I
> noticed some differences between newhidups in 2.0.4 (from Debian's
> 2.0.4-2.3) and the SVN trunk (rev 723) on an Evolution. Full diff is
> below, but here are the highlights:
>
>  * MGE HID 0.9 vs 1.0
>  * outlet.#.switch seems to have moved to the commands
outlet.#.load.{on,off}
>
> Then I found this in the ChangeLog:
>
>    * fix outlet.X.delay.{shutdown,start} and add temporary
>      commands (to be discussed) outlet.X.load.{on,off}. This
>      last would better be addressed through parameters of the
>      load.{on,off} command.
>
> For the on/off commands, couldn't we just use the upsrw-style
> variables and the existing names? It seems that optiups and mge-shut.h
> still use the outlet.#.switch variables.
I've needed to switch to the command style since there are 2 HID data:
1 for the off and 1 for the on. Not addressable easily with the upsrw
style, since in this mode, we have 1 (HID) data mapped to 1 nut
variable, with multiple values.
> Also, the older drivers seem to use 0/1 for the on/off values. We
> should probably stick with 0/1 for simplicity, or implement a "boolean
> parser" that maps "1", "on", "true", etc
to 1, and others to 0.
> Thoughts?
the simplicity vs user experience problem.
I've made this improvement considering the later, and it was long overdue...
since the data value lookup already exists, why not using it?
> ...
now, since there is a growing interest for the outlet collection, we
might start a thread. Remember that when I've started this, this
feature was only known on MGE hardware... So things might need to
evolve a bit.

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/