[Nut-upsdev] UPS driver for Online USV-Systeme Zinto A

[Christian "Eddie" Dost]

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" <ecd at brainaid.de>:
>
>> 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
ecd at brainaid.de             Belgium                voip +49 241 56529787