Hi Arjen,

it should be possible to add the line for "zinto" to the global 'command' structure, "Q1" and "F" replies are the same. I believe we should add a configuration option to select the protocol, as you say probing commands might hurt other UPSs. From the single "Q1" we can't auto-probe for zinto or not zinto...

Do you have a suggesting for this option? Should it be possible to select the protocol directly, i.e. just specify "zinto" or one of the others in ups.conf?

The output voltage setting is auto sensing, with lower input you get the lower 3 voltages, with higher input you get the higher 3 voltages.

I agree about ups.test.interval.

I do not fully understand the intention of the battery longtime option, the user manual is not clear about this either. I still would like to be able to set this to standard in case some UPS is configured the other way.

Do you have a suggestion for the configuration option to select the protocol in ups.conf? - I will rewrite this so it gets integrated into the blazer driver and send another diff...

Cheers,
Eddie

On 06/13/11 18:35, Arjen de Korte wrote:
Citeren "Christian \"Eddie\" Dost" <[email protected]>:

The basic differences in protocol are:

There is no "I" command, but a "FW?" command to request firmware
version. "Q1" and "F" are there.

Is the reply format the same? If so, this is trivial to add in the
blazer.c global 'command' structure, by appending a line

{ "zinto", "Q1\r", "F\r", "FW?\r" },

If not, this will have to be done via a configuration option in 'ups.conf'.

The main reason I wanted support for the Zinto UPS was to be able to
configure it. There are several settings to configure:

- ups.start.auto: Auto-Start after back online, boolean "AR0", "AR1",
request current setting with "AR?", response will be "AR0" or "AR1".

OK.

- ups.test.auto: Enable or disable automatic selftest, command "ATx",
same as "ARx" above.

This is (too) similar to the 'ups.test.interval' we already have. I
propose to map these values to either '0' (no automatic testing) and the
number of seconds between tests (automatic testing enbled).

- battery.energysave: Turn off load when on battery and load is very
small, command "GRx", same as "ARx" above.

OK.

- battery.discharge.longtime: Configure UPS to longtime discharge
(small load for long duration), command "SDx", same as "ARx" above.
"SD1" means standard, "SD0" means long time discharge.

It's unclear to me what this actually does. Is it used to allow deep
discharging the battery (what nut calls battery.protection on/off) or
does it change the threshold when the UPS decides the battery is low
(this would need to be lower in case of high rate discharge). I
sincerely hope it is the first, otherwise the engineers at Zinto did a
lousy job. You need to measure the load when running on battery anyway,
so adjusting this automatically is trivial.

- input.sensitivity: Configure trigger points for low/high input
voltages. Command "IPx", where "x" is "N", "W", "G", or "?" for
normal, wide, generator input and "?" to request current setting.

OK.

- output.voltage.nominal: Configure output voltage when running on
battery. Command "Vxxx" where "xxx" is 220, 230, 240 or 110, 120, 127.
This setting is echoed back in the "F" command.

Is this auto ranging (ie, a low mains unit would allow 110, 120 and 127
and a high mains unit 220, 230 and 240)?

If we can design a probing scheme to detect the "FW?" command maybe
and add these settings to the blazer driver, I'd agree to integrate
the code.

Like it or not, but the chances that a separate driver with the above
properties would make it into mainstream NUT is close to zero. The added
value of these settings by no means justifies the added maintenance
burden that would be required by adding another one.

Auto detection of models in this class of UPS devices is limited. We
already know of several units that lock up if you send them unsupported
commands, so probing with a command and see what's returned is not
likely to be included. It would be less risky to add a configuration
option to select a model instead.

Best regards, Arjen

--
___________________________________________________brainaid_____________
Christian "Eddie" Dost                             phone   +32 4 2900870
                            Rue des Raines 13      cell   +32 484 469677
                            4800 Verviers          cell +49 1577 6655034
[email protected]             Belgium                voip +49 241 56529787

_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Reply via email to